Re: Symlinks from Tools to Applications

[Richard Frith-Macdonald]

On 9 Mar 2007, at 10:41, Nicola Pero wrote:

> > > The reason I proposed this was to overcome the limitation of  
> > > needing an
> > > application's dll's to be in the search path when the application is
> > > loaded.
> >
> > Yes ... but the standard windows mechanism for doing this is to use
> > the registry ... (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
> > \CurrentVersion\App Paths) which solves the problem of automatically
> > locating the dlls efficiently and simply.
>
> What about just installing gnustep-base.dll into the Windows system  
> directory ?
> Then it would be automatically found with no need for registry  
> entries (the
> registry is a nightmare)! :-)
>
> But the real issue is that we need to start versioning DLLs.

and resources associated with them ...

> In fact, versioning looks like being the really hard problem,  
> because under
> Windows it's a total mess. :-(
>
> The only real solution I can think of is going the Unix way and use  
> the filename
> to version things, so we'd have Renaissance-0_8.dll and  
> Renaissance-0_9.dll
> and your program would be linked to one of the two, including the  
> version number,
> to avoid conflicts.
>
> Presumably on MinGW gnustep-make could automatically create  
> versioned library
> names such as Renaissace-0_8.dll and Renaissance-0_8.a ?  And then  
> convert
> -lRenaissance into -lRenaissace-0_8 when preparing the link  
> commands on Windows ?
>
> I think I can make that work efficiently if there is some agreement  
> that it is
> the way we want to manage versioning on MinGW.

If you put multiple versions of the dll in the windows system  
directory, even with versioning of the dlls, you won't read the  
correct GNUstep.conf and you will load the wrong versions of  
resources etc.  You also have the problem of other dlls that the  
gnustep dlls depend upon ... you would need to implement a versioning  
scheme for them too.  So implementing versioning for gnustep  
libraries doesn't even come close to solving the problem (NB. this is  
actually the case on unix too, it's just that on unix we tend to have  
package managers which handle most of the library dependency issues  
for us, and we generally don't have frequent changes in data  
resources, so we don't often notice problems with them).

I'm not saying that we shouldn't add library versioning on windows,  
only that it won't solve the problem on its own.  We need ...
versioning of gnustep libraries
versioning of any libraries gnustep uses
versioning of resources used by the libraries
Only once we have all three parts can we safely dump stuff in the  
windows system directory.

The idea of having the gnustep runtime distributions in their own  
subdirectories avoids all this conflict ... each subdirectory  
contains its own gnustep libraries, its own GNUstep.conf, and its own  
version of resources (and other files like libjpeg.dll that it  
depends upon).  So versioning is done by having a single version for  
the runtime package rather than individual versions on each file, and  
you know there are no dependency issues as the whole lot is in one  
directory.