Re: Symlinks from Tools to Applications

[Richard Frith-Macdonald]

On 9 Mar 2007, at 04:39, Christopher Armstrong wrote:

> Okay I looked at the updated README.MinGW file. I never really gave
> consideration for this approach as I was looking for something that
> would allow multiple GNUstep applications on the one computer without
> multiple copies of GNUstep.

Yes ... I think that's what we want once we have installers for each  
application (which implies building support for generating app  
installers into a makefile in a similar way to the current rpm  
packaging), but entirely standalone apps are good for now.

> I guess this approach is pretty solid for
> most standalone application developers, although we probably should  
> look
> at something a little more flexible for later on.

Agreed.

> > PS: We still need lots of thoughts on how to best package things for
> > end-users ... eg, I'd personally like to have a 'binary/end-user'  
> > GNUstep installer
> > that installs
> > gnustep-base.dll, gnustep-gui.dll, etc in the standard Windows DLL
> > locations ...
> > (and no MinGW and no development environment) so that if I want to
> > distribute binaries of Gomoku.app for Windows (for example) I just  
> > need to compile
> > it under MinGW and then I can just distribute the resulting  
> > Gomoku.app binary
> > folder as a .zip file, without having to include all the gnustep  
> > libraries that
> > will be provided by the GNUstep installer. (and still, people  
> > would be able to
> > start Gomoku.app by just double-clicking on Gomoku.exe).
>
> Another approach that I didn't mention in that email, that may
> "simplify" things somewhat is to use the Windows resource compiler to
> include simple resources such as .gorm files and icons and write them
> directly into a dll. NSBundle would obviously be modified to load
> resources in this manner, especially if the "bundle" it is handed is a
> .dll file. Only disadvantage is that every update to the bundle  
> requires
> a reship of all the images, so this approach is really only useful in
> *very* controlled environments.

I'm not sure that would help us ... with the current code apps  
generally have no problem finding their own resources, as they know  
their own directories, and equally, they have no problem finding  
shared resources as long as they can find the base library dll  
(because the base library can find GNUstep.conf, and that defines the  
paths to shared resources).  So the only real problem with multiple  
applications sharing a single GNUstep installation is with how the  
app locates the gnustep-base dll (and other dlls) in that installation.

> Yet another, but more disturbing ;-) approach for applications is to
> compile each application into a .dll, and shove a small executable in
> the .app wrapper to dynamically locate all the appropriate .dll paths,
> add them to the dynamic search path (windows LD_LIBRARY_PATH
> equivalent), and then load the application .dll. Gaim on Windows uses
> this approach; the only disadvantage is that it is more of a nusiance
> with GDB, but I guess we just make it optional if people want to use
> this approach. The obvious advantage is that an application can be  
> moved
> around, and just locate any information it needs from the registry and
> GNUstep.conf file (an .exe can do anything we really want it to  
> do). It
> could even link against frameworks without having to copy the files  
> into
> the Library/Tools directory for each framework, as we just insert the
> correct framework version into the dll search path.

The (seemingly) simplest solution to me is ...

1. a 'runtime' installer which places the gnustep libraries (and any  
of their dependencies) in a directory on the disk, and writes to the  
registry the location and version of the installation.
2. application installers which locate an existing copy of the  
runtime installation, and write the 'App Paths' registry key for the  
application to specify the path to the installed dlls.

Now, since we have set the 'App Paths' registry key for the app, any  
attempt to run that app will use the specified path to locate the  
base library (and other dlls in the runtime package).  The base  
library will then use its GNUstep.conf to locate any other shared  
resources the app needs.  Setting the 'App Paths' registry key allows  
the app to be moved around after installation

That gives us a simple, easy to use setup with multiple apps sharing  
a single copy of the GNUstep runtime.

However ...

The process of location of the shared runtime installation could be a  
little more complex ... we might have multiple copies of the shared  
runtime installed.  But a registry key can have multiple values set,  
so the application installers could check for that, and if multiple  
copies of the runtime are installed, offer the user a choice of which  
runtime to use.  This could also support versioning ... we could have  
different runtime versions installed and application installers could  
associate the applications with the appropriate version.

The biggest problem is what happens to apps if the runtime is deleted  
or moved (a clean uninstall should not be a problem as we could have  
the uninstaller check for apps using the runtime and warn and give  
the user a choice of actions).  The best we could do in this case  
would seem to be to use the approach you outline of having an  
executable check for the existence of the runtime before loading the  
main app, and display a useful error message if it is not found  
(possibly even search the disk to see if it can find where the  
runtime has been moved to).  Perhaps that's just too complex to be  
worth bothering with though.