> 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 _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
