Re: g-libs renaming and DIR emulation

[Hans Breuer <hans breuer org>]

At 01:34 02.10.01 +0300, Tor Lillqvist wrote:
>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.
>
Ooops. So we finally have some misunderstanding :)

>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'.
>
Which IMHO makes the decision to use the libtool convention more 
questionable ...

> > [...]
>
>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?
>
As I already said: it's a matter of opinion. Changing it now is 
definetly less worse than changing after the first official
2.0 version. But if it's gets changed it probably will be for a 
long time. And IMO it's inconsistent with the native win32 paltform.

> > 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.
>
Somebody else has done it wrong before us, let's do it again ?

> > 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.
>
> [...]
So if a function gets added and some bugs are fixed every app needs
to be recompiled and redistributed, though they aren't using the
new function. This is at least not the way I always understood the
concept of dynamic libraries, but even Microsoft appears to trade
bandwidth against 'dll hell' nowadays ...
 
> > >- 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.
>
I guess I should change the platform than :-)
 
> > 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.
>
But the version you removed was already called g_opendir, ... to avoid
this kind of trouble. So link or runtime problems shouldn't have happened.

To protect against compile time problems I was suggesting

#ifdef _MSC_VER
#define opendir g_opendir
....
#endif

One could even use

#if !defined (HAVE_DIRENT_H)
#define opendir g_opendir
....
#endif

> > [...]
> > >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.
>
Oops again. My removement suggestion wasn't meant too serious ...

	Hans

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