[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNUSTEP_INSTALLATION_DOMAIN
From: |
Sheldon Gill |
Subject: |
Re: GNUSTEP_INSTALLATION_DOMAIN |
Date: |
Fri, 13 Oct 2006 10:28:32 +0800 |
User-agent: |
Thunderbird 1.5.0.7 (Windows/20060909) |
Nicola Pero wrote:
Would it be an idea to have an option that decides what kind of tree is
going to be used like:
GNUSTEP_FS_STRUCTURE=[FHS|GNUSTEP|WINDOWS|SOLARIS]
We're not far from that ;-) ... that option will be used when configuring
gnustep-make.
It is -base which decides what goes where so we shouldn't we really be
configuring base, not -make?
Decoupling the dependencies is a good thing, IMHO.
You would be able to change your filesystem structure at any time by
editing your GNUstep.conf.
GNUstep.conf is initially created by gnustep-make, so it makes sense to
have the option there.
Yes, but it doesn't need to be. It's a development tool.
Things should be decoupled ... -make and -base don't really talk or depend
on each other.
Not entirely true. Currently -base depends on -make for configuration.
Everything is driven by GNUstep.conf. You'll be able to use -base (/any
other GNUstep software)
without -make if you want, if you set manually everything in GNUstep.conf.
That's right. Yet if -base generated GNUstep.conf then you wouldn't need to do
that. You could replace -make with any other tool that could translate from the
GNUmakefiles.
We just need to save the configured filesystem structure in GNUstep.conf,
and use it to set GNUSTEP_APPS etc. in common.make, and we're almost done
(except
that a few things, like GNUSTEP_INSTALLATION_DIR, will no longer work
in that
context). ;-)
Then every application, at launch time, must set up the whole fs structure?
Yes ... we're not really "almost done". :-( ... we also need to have
gnustep-base load
the directory structure from GNUstep.conf and use it when searching for stuff
at runtime :-/
For long lived processes this might be fine but for short lived tools you're
imposing a considerable startup delay.
I added PLATFORM_SUPPORT as a step in avoiding that.
If you said something like:
GNUSTEP_INSTALLATION_DOMAIN=PLATFORM_LIBS
you'd get your library installing into /usr/lib and so forth.
So any GNUSTEP_* spec uses OpenStep domain layout.
Any PLATFORM_* spec uses the local platform specifics.
For consideration, isn't GNUSTEP_INSTALLATION_DOMAIN a little too
confusing?
I'd prefer something a little more like:
GNUSTEP_INSTALLATION_DIR (we'd have to change some -make internals)
The problem with this is that it would break backwards compatibility ;-)
>
There are makefiles out there that might be using it in the old meaning.
We can't break those, at least not when they are used in the old context. ;-)
Well, yes. Making it *ION_DIRECTORY would solve that while keeping the semantic
idea.
GNUSTEP_INSTALL_INTO
GNUSTEP_INSTALL_DESTINATION
or perhaps we should be thinking more along packaging lines...
GNUSTEP_PACKAGE_LOCATION
Packagers can easily add a line to their makefile or preamble this way...
I don't really have an opinion, I like GNUSTEP_INSTALLATION_DOMAIN but
we can change the option name, it's not a problem. :-)
Comments/suggestions on the name are welcome. :-)
Cool. Others?
Regards,
Sheldon
Re: GNUSTEP_INSTALLATION_DOMAIN, Richard Frith-Macdonald, 2006/10/10
Re: GNUSTEP_INSTALLATION_DOMAIN, Dennis Leeuw, 2006/10/10
- Re: GNUSTEP_INSTALLATION_DOMAIN, Nicola Pero, 2006/10/10
- Re: GNUSTEP_INSTALLATION_DOMAIN, Sheldon Gill, 2006/10/12
- Re: GNUSTEP_INSTALLATION_DOMAIN, Nicola Pero, 2006/10/12
- Re: GNUSTEP_INSTALLATION_DOMAIN,
Sheldon Gill <=
- Re: GNUSTEP_INSTALLATION_DOMAIN, Nicola Pero, 2006/10/12
- Re: GNUSTEP_INSTALLATION_DOMAIN, Richard Frith-Macdonald, 2006/10/13
- Re: GNUSTEP_INSTALLATION_DOMAIN, Hubert Chan, 2006/10/13
RE: GNUSTEP_INSTALLATION_DOMAIN, Adam Fedor, 2006/10/11