Re: Symlinks from Tools to Applications

[Christopher Armstrong]

Hi

Richard Frith-Macdonald wrote:
> 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.
I've been investigating the use of WiX for creating installable 
packages. Unfortunately, it is not really suited for the kinds of things 
we need to be able to do in an installer. I'll try to explain the reason 
why, but I believe it boils down to creating a logistical nightmare if 
we change directory structures or the files included with a program. It 
logically separates groups of files into Components, but it will not let 
these "Components" be split over a file hierarchy but rather only within 
the same directory. This doesn't let us, for example, split an 
application wrapper into a number of  interface files and frameworks, as 
each directory within the framework needs to be a separate component, 
and it sort of makes the assumption that files are always to be 
installed in the same location (this is not really flexible enough). If 
you could imagine trying to use it with something that contains Unix 
paths such as MinGW, there is no logical way to separate along such 
lines as gcc-core, gcc-objc, gcc-g++ etc as their files are split across 
many directories.

It also associates GUIDs with the components, which means that a 
component is not likely to "change" at all. It was really designed for 
.NET applications which only consist of a bunch of local DLL's and an 
executable, not the complex app wrappers we have. If a component has its 
files changed, we need to reuse the same GUID, which is near impossible 
to handle in makefiles. The only advantage it really has is component 
tracking for removal and upgrading, but its idea of a component is too 
out of step with GNUstep such that it is too much of a headache.

NullSoft's installer (NSIS) seems to be a better option, as we can just 
hand it a directory and tell it to copy it to a location, then continue 
to execute some custom commands. It is scriptable as opposed to WiX, 
which is declarative (XML files). MinGW use it for their installer, so 
we can use this as a base to build a "Dev environment" installer. 
Unfortunately the script consists of macros and a stack based language, 
but this shouldn't be too much of an issue as it at least permits some 
logic handling and functions. It has been used in complex projects such 
as Firefox and is in fact portable across x86 to FreeBSD and Linux (not 
that we'd necessarily do this). I can't seem to find other solutions 
that are free and open source (anyone know any?)

> 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.
> 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.
I think it should be fairly simple to get the makefile package to 
generate installer scripts for either NSIS or WiX.

Regards
Chris