[Top][All Lists]

[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: Sun, 18 Feb 2007 10:02:00 +0000

On 18 Feb 2007, at 02:28, Christopher Armstrong wrote:


I've thought a bit about this one, and perhaps we could go for a more sophisticated solution, so that when we compile an application, it generates a shell script that is designed to start the application and is placed in a "normal" FHS directory e.g. /usr/ bin or /usr/local/bin.

For example, if we were compiling an application called GNUMail it would generated a "GNUMail" shell script, and this would be installed in /usr/local/bin when I run "make install" (or "gmake install").

It would initialize the GNUstep environment if necessary, and then start up the application. Not exactly speedy, but perhaps more system integrated. AFAIK several other multi-platform applications such as OpenOffice.org and Azereus use this approach due to their internal filesystem layouts. The debian packagers use a similar approach for GNUstep apps.

While something intuitively offends me about using shell scripts (perhaps just the efficiency thing, I don't really know), I have to agree that this would most likely be better than symlinks ... it is more versatile and portable.

That being said, IMO we *need* gnustep-make to be able to build windows packages for applications. Let's say gnustep-make supports automatic creation of WiX packages for instance ...
You do 'make wix' or something like that, and it builds your package.
The user double clicks the package to get the installer to install it, and as part of the installation process the installer asks the user if it should create a link to the app from the desktop or somewhere else. Then the user just has to double click the app to run it.

Adding support for building packages for different systems to gnustep- make is too big a job to ask Nicola to undertake on his own (especial;y windows packages when, afaik, he doesn't even own a windows machine), but it's probably something that, with his advice, could be largely separate and undertaken by different people. Maybe Nicola won't agree that package building should be part of gnustep- make, but it seems a natural place to put it to me (though add-ons to do it may be possible) We already have RPM package building support (under-used in my opinion) so I think the two most important additions are:
1. windows package building
2. source package building ... something that automatically tracks dependencies, downloads all the source code needed, builds it all, and installs it all. I think gentoo does this, and perhaps we could rip off their system. This would give us something akin to a 'universal' package builder (especially if we could make our packages such that the builder could bootstrap itsself, if necessary, as the first part of the process). Maybe this is too big a task even re- using gentoo code ... just an idea.

It might even be worth putting the openapp style scripts in a system bin directory as well, something like "gsopenapp" and "gsdebugapp" to save messing around with
". /usr/local/GNUstep/System/Library/Makefiles/GNUstep.sh"

I would have thought that the new filesystem layout would do that automatically (stuff which normally goes in /usr/GNUstep/Local/Tools would go in /usr/local/bin). As I understand it, sourcing GNUstep.sh should only be needed when building GNUstep software using older makefiles anyway (unless you have failed to set up library p[atchs in /etc/ld.so.conf or equivalent).

for the 90% of cases we don't want to source the GNUstep init scripts. Not that such a solution is a replacement for this script, but rather a complement.

On Windows for example, I think that we should create a simple loader application that sets up the environment to locate the various framework and tool paths to locate relevant DLL's using registry settings for the GNUstep location, and then spawn the application. Much like a binary or script form of openapp. We could then create shortcuts to these and put them in the start menu. An alternative approach is a full-blown Explorer shell addin (caution needed as it requires COM and a MS compiler).

I believe there is a better way on modern windows ... I have spent quite some time researching how to make things work more smoothly under windows, and I came across the information that it is possible to set (in the registry at HKEY_LOCAL_MACHINE\Software\Microsoft \Windows\CurrentVersion\App Paths\...) a per-application setting of where to find the DLLs the application uses. So when we install an application, we could set up this registry key and the app would find the correct set of DLLs and just run smoothly. As I understand it, windows automatically tracks moving or renaming of the app and alters this setting accordingly, so one it is set up a user should be able to move the app around without breaking things (though I have no idea how reliable this is).

Anyway, I think it would be good if 'make install' would set this registry key up, and any package we create would also set the key up.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]