g-libs renaming and DIR emulation

[Hans Breuer <hans breuer org>]

At 11:56 01.10.01 +0300, Tor Lillqvist wrote:
>(I hope you don't mind if I include gtk-devel-list and gimpwin-dev in
>this discussion.)
>

Hi list,
this is not really a reply, but my complete original mail to Tor.
I would like to here other opinions on the renaming of gtk libs
and the inclusion of a g_<open|read|rewind|close>dir emulation.

Thanks in advance,
	Hans

(The original mail follows)

Hi Tor,
sorry for complaining, but I would have preferred if two of your
recent changes would have been discussed on the mailing list 
first - or even could be avoided :)

Renaming from glib-$(major.minor).dll
-------------------------------------
  to libglib-$(major.minor.micro).dll

How far should it go ? Do you plan to rename all the gtk+ libs ?
Even Gimp's libs ? What about external libs ?

Some of my reasoning:
Adding the lib prefix to glib gives three libraries in one name,
though it is a matter of taste it's at least not mine ...

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.

IMO using the cyg prefix is a different issue and does not necessarily
require 'lib' for the other cases. Forcing it for msvc build may give
the impression that libtool is concerned, though it probably won't
in the near or mid future. 

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

If the real reason for adding the lib prefix was to get different
library names for early - almost 1.2.x versions - and the new
almost 2.0 versions, shouldn't we try to convince the gtk+ people
to bump the version to 1.9 ?


Separation of the DIR emulation
-------------------------------
If I see it right your supposed sollution is that every lib
or apllication needing it (when compiled with MSVC) should
include the dirent.lib, right ?
But this would introduce massive makefile and binary bloat
to solve a problem, which alreay was solved. Almost any 
larger app needs DIR, even gtk.dll uses it. 
If there were conflicts with the duplicate definition and
mingw, 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.

Kind regards,
	Hans

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