Re: Symlinks from Tools to Applications

[Christopher Armstrong]

On Fri, 9 Mar 2007 06:25:07 +0000, "Richard Frith-Macdonald"
<rfm@gnu.org> said:
> > 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.

Most developers would want to make these decisions themselves instead of
leaving it to users. In that case, it should be possible for application
developers to force a particular major version number for
libraries/frameworks for use with their application.
>
> 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.

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. As we can't take advantage of delayed DLL loading without some
kind of complex thunking mechanism or compiler support, we want to be
able to decide at runtime what version of a library or framework we wish
to load. I hadn't thought of the other advantages such as the user
uninstalling the GNUstep libraries.

Going back to application installers, I do believe we could use WiX to
create application installers, but I'm not sure how I should go about
modifying the gnustep-make package so that I can add the relevant code
to it so that merge modules and msi packages can be created. Is there
any information or advice for doing this? 

Practically, we need to store a file with everyones source code base
that contains a list of "names" alongside a generated GUID (128bit
unique identifier). These GUIDs only need to be generated once, but they
need to kept for future creation of installation packages so that old
versions of the package do not conflict with new versions (but are
removed instead). A developer must keep this file with their source code
if they want to continue to generate safe packages. 

I also need to know if we can use shell utilities from the makefiles to
maintain such a file (it would be a text-database file). I'm also unsure
of the structure of the makefile package. I should also warn that we
would need specific code for each type of makefile output (palette,
bundle, application, library, framework; these are all slightly
different).

On this note, we should probably continue use the Inno installer for the
rest of GNUstep as much of it would require hand-crafted WiX files
(especially MINGW). However, we could (probably) move the GNUstep
installation part over to WiX given some time. As the latter is more
likely to be affected by versioning issues than MINGW, we could continue
using Inno or the like for a MINGW/GNU libs installation, with the
possibility of a small hand-crafted GNU libs WiX file. 

Something to think about.

Regards
Chris
-- 
  Christopher Armstrong
  carmstrong ^^AT^ fastmail dOT com /Dot/ au