Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
Message-ID: <3C1A35F6.8050909@ece.gatech.edu>
Date: Fri, 14 Dec 2001 12:25:10 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
CC: cygwin-apps AT cygwin DOT com
Subject: Re: Restructuring gettext
References: <3C18EBA9 DOT 9030102 AT ece DOT gatech DOT edu> <0b5501c184be$8639eb80$0200a8c0 AT lifelesswks>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)

Robert Collins wrote:

> ----- Original Message -----
> From: "Charles Wilson" <cwilson AT ece DOT gatech DOT edu>
> 
>>However, this means that the new gettext dll is not backward
>>
> compatible
> 
>>with packages linked against the old dll  So, I've split it up into
>>
> two
> 
>>packages, and provided a "compatibility' package:
>>
> 
> Ouch. Do you know why it's not compatible? (i.e. is auto-import breaking
> something?)


Well, whaddaya know.  I replaced my cygintl.dll with cygintl-1.dll and 
wget/uuencode/etc still worked.  I just assumed because I changed the 
header files (back to the original) and was no longer declaring things 
"__declspec()" that that consitituted an API change.

However, by (partially) switching over to libtool-based dll-building, 
libtool imposes its own versioning: the new DLL's *name* is different, 
and will continue to be different (especially once we get the new devel 
libtool working, and I switch gettext fully over to libtool-based 
dll-building).  So, even if there is NO incompatibility, the name change 
itself is necessary and significant.

 
>>other than perhaps to add a (not real) dependence on libintl0 in
>>gettext's setup.hint to force an install...
>>
> 
> Why? If gettext needs libintl1, and sharutils et al need libintl0, then
> anyone who updates will get libintl0 automatically if they have
> sharutils et al installed.


Hmm...I want to test this first....

 
> gettext should only depend on libintl1 IMO.


No lying, then?

  
> IMO we can take steps to reduce the occurence of this: IIRC every time
> it has happened it's been a .dll splitout from the original package
> issue.


Yep -- it's always tied to package renaming, and that (hopefully) only 
occurs on splitting.  Or stupidity.  (I'm still not sure why I named 
some of my graphics lib packages "libfoo" and others merely 
"foo"...libtiff vs. jpeg?  And let's not even talk about "jbigkit"...)

--Chuck

P.S.  McNultyism: I'm out of email contact for the next several days. 
Back on Monday.