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

[Hans Breuer <hans breuer org>]

At 11:35 27.10.01 +0300, Tor Lillqvist wrote:
> [...]
>
>Again, remember that we are dealing with *development versions* here,
>and minor breakage now and then is expected. 
You don't tell it to me, do you ? 
[ 
  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.
]

>Especially on the Windows
>platform, where there aren't well established conventions for library
>names of common open source software, etc. 
You have established (or used) conventions which I followed most 
of the time, with small additions, i.e. 
- don't make it necessecary to 'install' headers/libs like it is on *nix
- don't require specific registry settings if it simply can be done
  from information already available and moving with the dlls
- 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
- 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
- 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
- AVOID to rename DLLs with any small api addition, because IMHO
  it totally defeats the purpose of dynamic loadable (and exchangeable)
  libraries ...

>As there is one convention
>used by a tool that the majority of open source developers from Unix
>are familiar with, and there are many people who are interested in
>cross-compiling from Unix for Win32, why not use that?
>
Yeah, I missed the other axiom: 'Almost all developers for gtk/win32
are developers coming from Unix'. (And they love auto-make-lib-tool:)

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.

> > I would like to here other opinions on the renaming of gtk libs
>
>I think you are flogging a dead horse here. 
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)

>Is it really such a big
>deal if the DLL names change while in the development phase, when the
>API and naming conventions etc by definition are unstable?
>
IMO it isn't the renaming which sucks but the (missing or short ended)
convention and consistency. 
Again, for me: 'Do it like libtool' is simply not enough reasoning.

Looking on Linux gives:

lrwxrwxrwx    1 [...] libglib-1.2.so.0 -> libglib-1.2.so.0.9.1
-rwxr-xr-x    1 [...] libglib-1.2.so.0.9.1

You are suggesting (enforcing?!) to use the adapted later name for win32 
dlls, I'm saying the former name is much more appropriate for these dlls,
because:
- it's the generic one and many apps done care about minor api additions
- the windoze loader can (and will) tell you about missing functions
- the real (intern) version can be shown dll-contained via the
  version property page (version resource in rc file)
- Windoze does neither provide links in the directory tree nor
  allows to (simply) change the library name to use with compiled 
  binaries.

[The 'lib' prefix is just an additional IMHO un-appropriate 
 cosmetic issue]

But i'm repeating arguments and could as well do something which is
more fun ... 

	Hans

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