Re: g-libs renaming and DIR emulation

[Tor Lillqvist <tml iki fi>]

Hans Breuer writes:
 > >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.

I didn't say anything about Cygwin. The three ways I meant were the
auto*+configure+libtool way, the makefile.mingw and gcc way (mingw),
and the makefile.msc and MSVC way.

Cygwin-targeted builds of course use libtool, which nowadas produces
cyg-prefixed DLLs.

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

I don't see it as such a big deal. If libtool by default wants to name
the DLL lib<name>-<age>.dll, why not accept that.

 > AFAIK it is possible to use the previous naming scheme with libtool
 > too.

Umm, on OS/2 it does set libname_spec='$name', but on all other
platforms libname_spec='lib$name'.

 > With simple handwritten makefiles for msvc the chances to not
 > break the win32 build are much higher.

I usd to be the same opinion too, but always had the thought back in
my mind "if someday the auto*/libtool stuff works well enough, I can
stop using these makefile.mingw's".

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

As long as you keep editing the makefile.msc's, that's fine with me
;-) But I do think we should keep producing the same name DLLs.

 > 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 we are talking about versions of libraries that aren't supposed to
be near production quality yet. Surely it can't much matter if the
name of the GLib or GTK+ DLLs on Win32 change at this point?

 > Yeah. A matter of taste 'library g library 1.3.8 dynamic link library' ...

Well, this is not the first time a library name is as from the
Department of Redundancy Department: libtermlib, or even Microsoft:
libc.lib and libcmt.lib, for instance.

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

GLib's configure.in says:

# Making releases:
#   GLIB_MICRO_VERSION += 1;
#   GLIB_INTERFACE_AGE += 1;
#   GLIB_BINARY_AGE += 1;
# if any functions have been added, set GLIB_INTERFACE_AGE to 0.
# if backwards compatibility has been broken,
# set GLIB_BINARY_AGE _and_ GLIB_INTERFACE_AGE to 0.

and

LT_CURRENT=`expr $GLIB_MICRO_VERSION - $GLIB_INTERFACE_AGE`
LT_AGE=`expr $GLIB_BINARY_AGE - $GLIB_INTERFACE_AGE`
LT_CURRENT_MINUS_AGE=`expr $LT_CURRENT - $LT_AGE`

(LT_CURRENT_MINUS_AGE is what gets used in the DLL name, and the above
expands to LT_CURRENT_MINUS_AGE = GLIB_MICRO_VERSION -
GLIB_BINARY_AGE.)

If I understand this right, this means that GLIB_INTERFACE_AGE doesn't
affect the DLL name, only GLIB_MICRO_VERSION and GLIB_BINARY_AGE. And
they grow in sync (thus keeping LT_CURRENT_MINUS_AGE constant), unless
backward compatibility has been broken.

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

I would say that of those people who even think of trying to build
GLib or GTK+ themselves on Win32, a large portion are in fact from the
Unix world, and to them the natural thing is to say ./configure; make
and expect a lot of complex stuff to happen.

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

It could, but then it shouldn't be called opendir/readdir/closedir,
but something in the style of
g_open_directory/g_read_directory/g_close_directory. Possibly with
some extra functionality thrown in, like (for instance) file name
patterns, recursion (ftw emulation, g_directory_walk?), globbing, or
whatever.

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

Yes, but if some app uses the dirent functions, it must get them
somewhere. It used to be that it got them from GLib and that the app
writer had to be careful to pretend dirent.h wasn't there when
compiling with gcc, if he wanted to also be compileable with
MSVC. (That's why for instance GIMP's config.h.win32 doesn't define
HAVE_DIRENT_H, even if it is there when compiling with gcc.)

Now, with those functions gone from GLib, the app can include
<dirent.h> always (and use the appropriate -I flag in MSVC
compilations).

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

Yes, I think so. I did at one point suggest that on the mingw list,
but I don't think people understood my concerns. I probably should
take it up again.

--tml