[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Symlinks from Tools to Applications
From: |
Christopher Armstrong |
Subject: |
Re: Symlinks from Tools to Applications |
Date: |
Tue, 20 Feb 2007 13:38:47 +1100 |
User-agent: |
Thunderbird 1.5.0.9 (Windows/20061207) |
Hi
Richard Frith-Macdonald wrote:
I had spotted that one, but was hoping that a more in depth study
would show up a way to work around it.
Another issue is that it doesn't support automated download of
dependencies as far as I can see, and the declarative nature of the
package files makes it hard to see how adding a dependency download
mechanism could be done cleanly.
The WiX idea of tagging everything independently to allow upgrade of
each bit separately is pretty attractive, but I think a better
solution for GNUstep is to have smaller packages able to download
dependencies automatically. The first format is simpler for
distribution on cd-rom, but I don't think that's what we are aiming at.
Perhaps we should devise an installer that can download, install and
upgrade various components as needed. On Windows these fall into roughly
these categories:
1. GNU (essentially binaries for stuff like libtiff, jpeglib, libxml2,
libiconv, libintl etc). Could perhaps share with gtk, but probably best
to keep our own copy to avoid DLL Hell issues.
2. GNUstep runtime (objc runtime, base, gui, and back + assorted
utilities, file system layout and tools)
3. MSYS and some extra utilities
4. MinGW compiler(s) and headers (gcc-core, gcc-g++, gcc-objc, w32api etc)
5. GNUstep Development (headers and libraries, ffcall, etc).
I was thinking an all-in-one installer, that let the user select between
a "user" and "developer" installation. The "user" one would contain 1 &
2 (possibly 3), the "developer" containing all of them. The MinGW
installer again has a good idea on doing this; we store an .ini file on
our web site and the installer downloads this to get the locations and
names of the packages needed to be extracted on a user's HD. To make
things more flexible, this file should store a archive name and version
so that we can work out what needs to be upgraded in the event the user
already has parts of GNUstep already installed. How to handle upgrades
is a little bit unclear, as we should remove old files instead of
extracting over the top (perhaps we can store a list of files that was
installed with a package?).
I must admit, apart from a cursory scan of search results from google,
I've only looked at WiX ... mostly because most of the references I
saw seemed to regard it as 'approved' or 'standard' pacakging tool.
It does sound like NSIS would be a better option though.
Seems to be best for normal Windows programs, that consist of COM
libraries and executables that use them, where components are bundled
into the same directory and only require generic registry stuff such as
inserting GUID's under HKEY_CLASSES_ROOT.
Cheers
Chris
- Re: Symlinks from Tools to Applications, (continued)
Re: Symlinks from Tools to Applications, Ingolf Jandt, 2007/02/23
Re: Symlinks from Tools to Applications, Gregory John Casamento, 2007/02/17
Re: Symlinks from Tools to Applications, Christopher Armstrong, 2007/02/17
- Re: Symlinks from Tools to Applications, Richard Frith-Macdonald, 2007/02/18
- Re: Symlinks from Tools to Applications, Christopher Armstrong, 2007/02/19
- Re: Symlinks from Tools to Applications, Richard Frith-Macdonald, 2007/02/19
- Re: Symlinks from Tools to Applications,
Christopher Armstrong <=
- Re: Symlinks from Tools to Applications, Richard Frith-Macdonald, 2007/02/20
- Re: Symlinks from Tools to Applications, Christopher Armstrong, 2007/02/20
- Re: Symlinks from Tools to Applications, Christopher Armstrong, 2007/02/26
Re: Symlinks from Tools to Applications, Nicola Pero, 2007/02/17