Re: [gimpwin-dev] g-libs renaming and DIR emulation

[Charles Wilson <cwilson ece gatech edu>]

Hans Breuer wrote:
> At 17:52 01.10.01 -0400, Charles Wilson wrote:
>
> > Tor Lillqvist wrote:
> >
> > [...]
> > First step is to make sure that the mingw and cygwin versions of libtool 
> > work properly.  However, that seems to require an intermingled set of 
> > updates -- use the latest versions of auto*, cygwin-1.3.3 or later, etc. 
> > We're a-working on it...
> Wow, this is exactly what I always wanted. First rely on a not yet 
> released part in your tool chain ... :-(

Not ideal.  Agreed.  I just am *trying* to keep you guys apprised of 
what's going on in the cygwin world.  Especially as it tends to spill 
over into the mingw world, as well.

> > > Note that this part of Hans's mail was based on a
> > > misunderstanding. The micro version number isn't included in the DLL
> > > name, it just looks like that as long as the micro version keeps
> > > increasing while binary_age is kept at zero...
> > Ah, I see.  So the release-micro-version-number is tied in to the 
> > libtool-ish "revision-of-current-interface" number?
> >
> > [...]
> >
> >
> > > but what Hans didn't
> > > like.
> > Hans!!!  :-(
> Maybe I should have been clearer in my original mail or my first 
> answer.
> My argueing was mainly against the libtoolish 'lib' prefix and
> only beside that about the IMHO questionable (more unnecessary
> downloads/updates than actually solved problems) of the addition
> of the 'interface age number' in the dll name (but not in the 
> import library name which does not include version numbers at
> all anymore)
>
> And even shorter: are the libtool naming conventions _really_
> appropriate for dlls builds with msvc for the _native_ win32
> platform ?

Yes.  Because the SAME issues of backward compatibility, "slipstream" 
updates, and whatnot still exist, no matter what platform you're on. If 
libglib-1.3-4.dll supports interface A, and then I add a new function -- 
old apps can still use the new DLL.  So the new dll should STILL be 
called libglib-1.3-4.dll, so I don't need to recompile all of those apps.

However, if I change the params of a function that was part of interface 
A, or if I remove a function that was in interface A, then the new DLL 
cannot be used by previously compiled functions.  The new DLL should be 
named libglib-1.3-5.dll so that it can coexist with the -4 version.

This "magic" happens if you follow the lt_current_minus_age convention.

> > I'll download current CVS and check.  Where do I do to get the 
> > win32-branch?  What repository, and branch tag do I use?  Or should I be 
> > looking at HEAD?
> It's HEAD. And before the currently discussed change it was building
> from glib over pango and gtk up to Gimp head (at least with msvc and
> short after my commits :)

Actually, I don't need to do this anymore.  Your earlier post showed 
exactly how the various version variable were computed.  Looks okay to 
me -- seems like the "libtool" math is being done *outside* of libtool, 
but that's okay -- as long as the end result is the same. :-)

--Chuck