Re: Symlinks from Tools to Applications

[Nicola Pero]

> But the real issue is that we need to start versioning DLLs.

Actually, I put a little more thought into that and it turned out that there
was an extremely simple and elegant solution.  Not sure why not/if other 
MinGW-based
projects are using it themselves.  Anyway, the implementation is already in 
trunk. :-)

Let me explain my solution to get full Unix-style DLL versioning under Windows. 
:-)

When you compile gnustep-base, you get two files:

 1. you have the actual DLL, gnustep-base-1_14.dll (the '-1_14' is the new 
addition; this is the INTERFACE_VERSION of your library, with the same 
semantics as under other platforms, eg Unix.  That is, if on GNU/Linux you have 
libgnustep-base.so --> libgnustep-base.so.1.14, here you have 
gnustep-base-1_14.dll)

 2. you have a 'link wrapper' library libgnustep-base.dll.a (always the same 
name, this in a way is the same as the libgnustep-base.so symlink!) that is 
only used at link-time (much like the libgnustep-base.so symlink!)

At link time, you provide -lgnustep-base on the linker line.  That link command 
will look for libgnustep-base.dll.a, and statically link the code in there.  
The code in there contains the calls that, at runtime, will actually load 
gnustep-base-1_14.dll.

If you now compile a new incompatible version of gnustep-base, say 1.15.0, then 
you'd get two files: gnustep-base-1_15.dll and libgnustep-base.dll.a.  Your new 
libgnustep-base.dll.a will now load gnustep-base-1_15.dll, so if you now link a 
new application, it will get a call embedded into it to load 
gnustep-base-1_15.dll.  Old applications will still load gnustep-base-1_14.dll 
though! :-)

You can now have both gnustep-base-1_14.dll and gnustep-base-1_15.dll with some 
apps
loading one and some apps loading the other one, with no possibility of 
confusion
(tested).  So if you want to deploy a new incompatible version of gnustep-base,
you can do so without any fear of breaking existing apps that use an older
version; the new version will have a different name, and each app is linked
explicitly to the DLL including the name (exactly like it happens on Unix).

When you link, the latest gnustep-base that you installed on your MinGW system
will be used to link (since libgnustep-base.dll.a will be the one of the latest
one you installed, very much like the libgnustep-base.so symlink will be the one
of the latest one you installed on GNU).  Normally you'd only have one on your 
development system btw. ;-)

This is exactly the same system used under Unix; the parallel is:

 libgnustep-base.so (the symlink) <==> gnustep-base.dll.a (the wrapper library 
pointing to gnustep-base-1_15.dll)

 libgnustep-base.so.1 (the lib linked into the app and loaded at runtime) <==> 
gnustep-base-1_15.dll (the dll that the app is hardcoded to load at runtime).

Looks pretty good to me.  I especially like the fact that the same versioning
system is used under Unix and Windows so you can expect the same semantics (and
the same features/problems!) on the various platforms. :-)

We now need to manage versioning of library resources and then we can pretty 
much 
install gnustep-base-1_14.dll directly into the Windows system folders knowing 
that 
you can install multiple versions of libraries and they should coexist (what 
about MinGW/dependency DLLs though ?). :-)

gnustep-base is not maybe the best example btw, probably a more standard library
such as Renaissance is a better example. ;-)

Thanks