Re: Symlinks from Tools to Applications

[Richard Frith-Macdonald]

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

> Hi
>
> 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.