Re: g-libs renaming and DIR emulation

[Hans Breuer <hans breuer org>]

At 11:56 01.10.01 +0300, Tor Lillqvist wrote:
>... 
>
>> Renaming from glib-$(major.minor).dll
>> to libglib-$(major.minor.micro).dll
>
>Actually it was from 
>	glib-$(major).$(minor).dll 
>to
>	libglib-1.3-$(lt_current_minus_age).dll
>
> [...]
>
>I think it is a good idea to have all three ways to build a certain
>release of GLib DLLs produce the same name DLLs and import libraries.
>
Huh ? The whole point of the 'cyg' prefix is to get a different name
for probably incompatible versions of the 'same' dll.

But I agree, that glib from msvc and mingw should be named equally
as long as they are interchangeable. Though I still prefer to not
declare libtools 'lib' prefix as new standard for the win32 platform. 
AFAIK it is possible to use the previous naming scheme with libtool
too.

>Eventually I probably would like to remove the makefile.mingw stuff
>altogether, and always use auto*/configure/libtool when bulding with
>gcc. 
IMO this is the main difference in our approaches. I always try
to keep the tool chain on windows as short as possible (everything
provided by msvc and perl if there's no way around it).

Maybe it's only my impression that with the standard  *nix tool
chain the auto* stuff is always the weakest link. And if it breaks
one often requires an auto* expert or at least knowledge with
three additional languages (perl, m4, bash).

With simple handwritten makefiles for msvc the chances to not
break the win32 build are much higher. If it breaks it usually
does at the def files, which should be simple to fix for
everyone (and would probably be required for the auto*/mingw 
built too ...
 
>For MSVC users there will still have to be the parallell
>makefile.msc files. (Unless one would require MSVC users to have
>Cygwin installed, and use the build/win32/cl-wrapper program as
>compiler. This does indeed work, at least almost...)
>
Do I need to say: please don't do it :-)

>> How far should it go ? Do you plan to rename all the gtk+ libs ?
>> Even Gimp's libs ? What about external libs ?
>
>Yes, the more places one can get rid of those separately maintained
>makefile.mingw files, the better.
>
I not really meant the mingw build simplification, which is always 
good. But renamining libraries with indifferent reasons appears to 
be a different issue.

>> But here are some 'hard' facts. Using the lib prefix may improve
>> consistency with libtool and *nix, but it does decrease it with 
>> the win32 platform conventions, even with earlier gtk+ versions.
>
>I think the possibility to be able to get rid of at least one set of
>parallell makefiles that have to be manually maintained is the reason,
>not name consistency with Unix per se. 
>
Can't disagree.

>The name of DLLs should be pretty much irrelevant to application
>developers, anyway, they only see the import library names.
>
Yeah. A matter of taste 'library g library 1.3.8 dynamic link library' ...

>> Another somewhat related issue is the addition of the micro version
>> in the dll name. IMHO the Windows loader is quite able to handled
>> micro api additions as may be shown by increasing the micro version
>> (missing symbols in older versions). If we include the micro version
>> in the dll name (as done on *nix)
>
>No, the micro version isn't included in the shared object name on *nix
>(Linux, Solaris, others?). The result of subtracting the interface age
>from the current interface number is. They arenot necessarily equal,
>although currently, when the interface age and binary age are zero, it
>is.
>
I knew that. Though my point was aren't the micro version changes
restricted to api additions or function renaming (i.e. not adding
an additional parameter to an already existing function.

If so the micro name addition would force gtk+ lib updates for
no good reason but a name change (if one does not use the api
additions). This may be no reason for people with unlimited
bandwidth.

BTW: my Dia port worked with you official gtk libs, though
I was almost always using cvs glib.

>> there is no such simple solution
>> like creating a symbolic link, but some users will complyin and others
>> will simply rename the dlls. Probably both things are not our intent,
>> are they ?
>
>All solutions are bad for some people in some way. I think what should
>be kept in mind is:
>
>- Maintaing separate parallel makefiles for mingw and msvc is a pain.
Agreed.
>- If such parallel makefiles are used, they should produce the same name
DLLs 
>  as the "standard" (libtool) does.
Why? I can't really see that libtool is the standard on win32, even not
for mingw builds.
>- Only very few people actually are interested in building GLib and GTK+ 
>  themselves on Win32.
>
This may be the egg-and-hen problem. As long as there is no 'simple'
build possible most people will try to avoid it. On the other hand
some people actively developing on win32 may be interested in using
as much 'native' tools as possible (and no emulations of a platform
which is better by defintion :-)

>> If I see it right your supposed solution is that every lib
>> or application needing it (when compiled with MSVC) should
>> include the dirent.lib, right ?
>
>Yes.
>
>> But this would introduce massive makefile and binary bloat
>
>Umm, one extra -I flag and one extra library? That's not very bad,
>isn't it? 
Ok. massive bloat maybe a little strong. But I've always thought
of glib as an additional system abstraction. Why should something
such basic as the DIR emulation _not_ be handled by glib ?
And what's the next small library to be linked in every app ?

> [...]
>> to solve a problem, which alreay was solved.
>
>No, the problem was not solved. Having the dirent emulation stuff in
>GLib was simply wrong, IMHO. It did cause various kinds of (minor)
>problems that had to be taken care of when building software for Win32
>with the mingw gcc.
>
>> why not simply wrap them like
>
>> #ifdef _MSC_VER
>> #define opendir ...
>> #endif
>
>> but still include them in glib (even in mingw glib builds), to 
>> avoid downstream problems with msvc builds.
>
>That would be possible, yes, but I still felt that the dirent stuff
>doesn't *really* belong in GLib. It was added early in the
>GLib/GTK/GIMP porting effort without really thinking whether it
>belongs there.
>
>(The real cause of the whole mess is that dirent.h is included with
>the mingw headers, and the functions in the always-linked-in
>libmingw32 library. 
Isn't such supposed to be solved by config.h / HAVE_DIRENT_H ?

>IMHO that is against the principle that code that
>compiles with MSVC should be compileable with mingw, *and* vice
>versa. But I don't think that can be changed now.)
>
Don't understand. Shouldn't mingw simply remove dirent.h and
unistd.h etc than :)

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