Re: GNUSTEP_INSTALLATION_DOMAIN

[Nicola Pero]

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

Thanks, I see your point ... which is a very good one :-)

You're suggesting that, for example, in a binary distribution (say, Debian)
you could install gnustep-base without installing gnustep-make.

Then you can also install any other GNUstep software that is binary packaged
by the distribution.  You don't need gnustep-make, because everything is
in the FHS locations and you're not building anything, you're just installing
binary packages.

I agree it would be a nice thing :-)

In that case, yes, you would need GNUstep.conf, yet you have no gnustep-make
installed.

I suppose the right way of addressing the issue is to create a
'gnustep-common'
package, that only installs GNUstep.conf.

Then, on top of that, you can install gnustep-make and/or gnustep-base;
you only
install gnustep-make if you want to build.

We could make all this explicit by extracting the creation of GNUstep.conf
into
a separate software ... to be installed before gnustep-make.  It sounds
very clumsy
though ;-)

At the moment, I'd leave everything as it is (a packager could still
install GNUstep.conf
in a separate package to get the effect above).

Moving the creation of GNUstep.conf into gnustep-base doesn't make much
sense,
because gnustep-make can't work without it.  You may want to use gnustep-make
without gnustep-base (eg, for building documentation or resources or java
stuff,
or for building using non-gnustep-base foundation libraries, eg on
apple-apple-apple
or gnu-fd-nil), and at the moment you can't build gnustep-base without
gnustep-make
anyway ;-)

Anyway, good idea to keep it in mind, I mean, yes, conceptually, the step
of creating
GNUstep.conf is separate from gnustep-make and gnustep-base.  It's a
"preliminary" step
if you want. ;-)




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

There is already such a delay, since we are already reading GNUstep.conf. 
I doubt
adding ten more lines or so to read would make any difference in speed. 
If we could avoid
reading the file altogether, that would be faster. ;-)

I imagine the 20 lines GNUstep.conf file will always be in the kernel
cache so it will
all be extremely fast.  Maybe we could benchmark it, but even for a Unix
command-line
utility that has to be as fast as 'grep' or 'sed' or those thingies, I'm
not sure
it would make a measurable difference.  If it makes a considerable
difference, presumably
you'd disable GNUstep.conf and just run from hardcoded values.  That would
work and be as
fast as you can get :-)



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

Oh ... I see.  I looked at that ... but the current idea/trend is rather
that, when you use the
Unix FHS (for example), the GNUstep dirs are mapped onto local Unix FHS
dirs.  All
access to the dirs goes through the API anyway.  So,
GNUSTEP_SYSTEM_ROOT/Tools ends up
mapped into /usr/bin.  GNUSTEP_LOCAL_ROOT/Library/Libraries is mapped to
/usr/local/lib, etc.  Of course the libs have to do the mapping from the
GNUstep API
to the native filesystem.  This mapping comes from GNUstep.conf (or is
hardcoded in
the lib).

So, rather than have both the GNUstep filesystem and the native filesystem
in the same
installation, you'd have either the GNUstep one or the native one. ;-)

Thanks