lib naming scheme consistency (was Re: 1.3.10 release candidates)

[Tor Lillqvist <tml iki fi>]

Hans Breuer writes:
 >   Probably I simply should have reverted your makefile.msc changes 
 >   instead of worrying about how to get the required changes back 
 >   into CVS, without breaking stuff which I absolutely dislike.

Please do if you find it necessary...

 > You have established (or used) conventions which I followed most 
 > of the time, with small additions, i.e. 

Yes, but those conventions are not inscribed in stone, I have also
changed my mind at occasions...

 > - don't make it necessecary to 'install' headers/libs like it is on
 > *nix

I now think this is not a good idea. Some software have their headers
organised differently in the sources than when installed, and you need
to have them "installed" in order for things to work. (I don't
remember the exact details, but FriBiDi was such a package.) Another
reason to avoid including directly from sources is not to risk getting
some non-public header (like config.h).

 > - don't require specific registry settings if it simply can be done
 >   from information already available and moving with the dlls

Absolutely agree. (The Registry stuff in GLib and pkg-config is just a
*fallback* in case some day somebody wants to do it that way. I
won't.)

 > - avoid to hardcode the Unix directory conventions /usr /etc (mixing
 >   programs over various branches of the directory tree.) in win32
 >   binaries. It may perfectly make sense for Unix system administrator
 >   to do this split, but at least was never convention on win32

I am not really sure I understand you here, but I think I agree. Do
you think it is OK to use Unix-style subdirectory names of a
(user-chosen) top-level installation directory, though? (I mean like
"include", "lib", "bin", "share" etc.)

 > - avoid to duplicate direcory branches in the depelopment tree
 >     My makefile.msc's, i.e. glib/makefile.msc :
 >        TOP = ..\..
 >        !INCLUDE $(TOP)\build\win32\make.msc
 >     Yours :
 >        TOP = ..\..
 >        !INCLUDE ..\build\win32\make.msc

Hmm, and if somebody tries to build glib with MSVC from a fresh
tarball? They have to copy the "build" subdirectory one level up?
Using the "build" subdirectory as included with GLib avoids this. (I
first got this wrong, too.)

 > - avoid (to make it necessary) to stuff all dlls or related files
 >   into c:\windows\system (which may have been convention on windoze
 >   in the early days, but even there are people able to learn

Absolutely agree.

 > - AVOID to rename DLLs with any small api addition, because IMHO
 >   it totally defeats the purpose of dynamic loadable (and exchangeable)
 >   libraries ...

Absoluteluy agree. But you should realize here that the GLib 1.3.x
vesions *are* incompatible. That's one reason they are called
"development" versions. That's why the LT_AGE number is kept at
zero. When GLib-2.0 is released, it will be increased each time
GLIB_MICRO_VERSION is increased, meaning that the DLL name will stay
the same even if new functions are introduced, as long as the API of
the old ones stays the same. (At least, this is how I understand it.)

 > Have you ever thought about the possibility that Unix users don't
 > need to know how there dlls are named (lib.so.la.a), because they get
 > a full blown compiling setup program? And that this is neither 
 > feasible nor appropriate for the windoze platform.

Windows users don't need to know the DLL name either, they use the
import libraries. In my setup, I create the GLib MSVC import library
as glib-1.3.lib. This happens to be the same name as it has had for a
long time (also when the DLL was called glib-1.3.dll). Isn't this just
what you want?

 > Yeah it certainly appears so. It was your convention so you are
 > perfectly free to change it at will, even without discussion.
 > (And I could as well do it the way I'm convinced is the right one)

Yes, if you are absolutely convinced, go ahead and change the
makefile.msc's... I won't mind.

--tml