[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Symlinks from Tools to Applications
From: |
Richard Frith-Macdonald |
Subject: |
Re: Symlinks from Tools to Applications |
Date: |
Fri, 9 Mar 2007 06:25:07 +0000 |
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.
- Re: Symlinks from Tools to Applications, Nicola Pero, 2007/03/09
- Re: Symlinks from Tools to Applications, Nicola Pero, 2007/03/09
- Re: Symlinks from Tools to Applications, Nicola Pero, 2007/03/09
- Re: Symlinks from Tools to Applications, Nicola Pero, 2007/03/09
- Re: Symlinks from Tools to Applications, Nicola Pero, 2007/03/09