Re: g-libs renaming and DIR emulation

[Tor Lillqvist <tml iki fi>]

(I hope you don't mind if I include gtk-devel-list and gimpwin-dev in
this discussion.)

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

Umm, yes, sorry... 

> 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

where the 1.3 presumably will change to 2.0 when GLib 2.0 is
released. lt_current_minus_age is the value of LT_CURRENT minus LT_AGE
(which expands and simplifies to GLIB_MICRO_VERSION -
GLIB_BINARY_AGE). This is the same name as libtool produces for the
DLL using standard configure-generated Makefiles.'

The intention (I think) is that when there is a compatible change to
API (in a micro version, for instance from 2.0.0 to 2.0.1), both
GLIB_MICRO_VERSION and GLIB_BINARY_AGE are incremented, and the DLL
name thus stays the same.

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.

Eventually I probably would like to remove the makefile.mingw stuff
altogether, and always use auto*/configure/libtool when bulding with
gcc. 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...)

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

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

The name of DLLs should be pretty much irrelevant to application
developers, anyway, they only see the import library names.

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

> 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.
- If such parallel makefiles are used, they should produce the same name DLLs 
  as the "standard" (libtool) does.
- Only very few people actually are interested in building GLib and GTK+ 
  themselves on Win32.

> 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? And I don't see how it would affect binary size a bit, if
the dirent functions aren't used, no need to mention dirent.lib in the
makefile, and even if mentioned, nothing will get linked in from it
unless needed? And if it gets linked in, it isn't very much code. Or
have I missed something?

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

--tml