Re: Another thought about GNUSTEP_INSTALLATION_DOMAIN

[Nicola Pero]

> I'm getting a bit confused trying to follow this thread. [...]

Yes, the thread might be confusing.  Here is a summary of the changes
that we are discussing in the thread --

 * Using GNUSTEP_INSTALLATION_DOMAIN instead of GNUSTEP_INSTALLATION_DIR. 
You
can keep using GNUSTEP_INSTALLATION_DIR and it will keep working.  But you
will
not benefit from the new features (DESTDIR, installation in Unix FHS). 
So, if
you're not interested in the new features, there are no changes,
everything that
used to work will still keep working.  If you are and/or might ever be
interested
in the new features, I recommend you switch to using
GNUSTEP_INSTALLATION_DOMAIN
(this is a tiny change).  Since software authors usually are keen to see
their
software being as deployable as possible in all sorts of situations, I
strongly
recommend you switch.

 * Agreeing on the guidelines for setting the default
GNUSTEP_INSTALLATION_DOMAIN
of software.  All software that we (GNUstep project) manage directly will
of course
be changed to comply with the guidelines, but that change (if there is a
change)
will be silent to you as a user, ie nothing should be broken by it.  Worst
case is
some libraries or tools will be moved from one domain to the other one;
you can
still link to them or invoke them in the same way though.  You are
free to change your software to comply with our guidelines or not; we
can't force you.
The software will still work if you don't comply. ;-)
But I recommend you switch to the guidelines, once we have them, so that
users can expect
a consistent behaviour from all GNUstep stuff. :-)



> It was difficult enough adapting to the round of changes when
> GNUstep.conf was introduced, and I daresay there is still confusion
> amongst app developers as to the respective roles of GNUstep.conf and
> GNUstep.[c]sh.  While the benefits of FHS installation are nonzero,
> the amount of initial disruption and any possible divergence in OS X
> compatibility should be carefully considered.

I understand the confusion, and also the doubts about further changes. ;-)

Part of the reason is that we haven't really provided any real
benefits/simplifications
to end users yet.  We have been changing things, as part of our long-term
strategy,
but we have yet to deliver any real benefits!  That must be frustrating
for users.
I mean, you still have to source GNUstep.sh in the latest stable release and
all still works in the same way ;-)

But finally in the new release we'll have new powerful options that let
you integrate your GNUstep
installation very strictly with the native system.  It will be my pleasure
to write
detailed documentation on all that. :-)

At that point the benefits will be very clear ... so months/years of
discussions
and work on GNUstep.conf and other general reorganizations (by me,
Richard, and everyone
else involved) will finally produce the 'native integration' option that
is so key
and cool. ;-)

And that without sacrificing any of the existing functionality ... which
is not trivial
at all.  Hopefully at that point the reason for all the changes will be
more clear.

Thanks