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

[Hans Breuer <hans breuer org>]

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 ... :-(

>> 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 ?

>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 :)

	Hans
-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to 
get along without it.                -- Dilbert