[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.
From: |
David Chisnall |
Subject: |
Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac |
Date: |
Thu, 16 Sep 2010 13:26:22 +0100 |
On 16 Sep 2010, at 12:37, Richard Frith-Macdonald wrote:
> On 12 Sep 2010, at 21:16, Riccardo Mottola wrote:
>> I'm absolutely against having FHS as a default. It is against the
>> OpenStep/Cocoa philosophy! The best layout is the GNUstep layout with
>> prefix=/ in my opinion, although using /usr/GNUstep is sensible because it
>> is not such a great "clash" in a mixed environment.
I also prefer this, but it's worth noting that a lot of systems use a small /
partition and a larger /usr or /usr/local. I generally install in
/usr/local/GNUstep and then symlink stuff to /.
I think it's also important to do this if we are trying to attract developers
familiar from Cocoa - give them the FS layout that they are familiar with.
> Are you against it in every situation?
> The reason I ask is that there are a few different cases to consider ...
>
> 1. Hopefully, increasingly, people will be installing packages provided by
> their operating system distribution ... in which case the person who manages
> that package controls the filesystem layout, and the default in gnustep-make
> is irrelevant since it's not used. I expect this is the largest group of
> users already.
Most packagers don't bother with optional configuration, so the default means
that is what they will see. The FreeBSD packages, for example, use the GNUstep
layout because it's the default. As, I believe, do the Arch and Gentoo ones.
The Debian ones use FHS because they have a policy of using FHS for everything
even when it doesn't make sense.
This is especially true of something like GNUstep. For something like GNOME,
there are probably lots of people interested in packaging it for a given OS.
FreeBSD has over 100 GNUstep-related packages maintained by a single person
(thanks Dirk!), so expecting him to manually tweak the configuration of any of
them is probably not feasible.
By and large, packagers want to automate the packaging job as much as possible,
and that means having defaults that Just Work™
> 2. Similarly, there may be alternative packages provides ... eg a complete
> GNUstep desktop package ... which would again use the layout the package
> manager decides to use ... so the gnustep-make default is not used.
These are usually metapackages, so this is just a case of (1) being installed
as a dependency.
> 3. Experienced developers and users who habitually build from source will set
> whatever layout they like (and may even have more than one layout), and as
> long as my changes work properly, once they have set a preference it's
> recorded in their GNUstep.conf file so that the setting is retained when they
> update gnustep-make. So again, the default is not used (though obviously the
> first time they encounter the change these people will need to set their
> preference to avoid using the default).
Well, I probably think I am a reasonably experienced developer, and I wasted
half an hour after this change working out why my changes to -base didn't seem
to be being picked up by running applications. I then had to look in the
documentation and, eventually, worked out how to change -make back to behaving
as I expected.
> 4. An inexperienced developer installing from source ... this is the person
> who gets the default behavior.
Agreed.
> I hope I haven't missed a group ... obviously my aim is to target the people
> in the last group ... someone who is trying GNUstep for the first time and
> for whom we want the code to just work with the default configuration.
> Do you think that it's more important for these people to have stuff
> installed in a GNUstep file hierarchy than to have programs run and example
> code build?
I don't see a conflict between the two. LanguageKit loads frameworks using
NSBundle so that you can distribute a portable .app bundle with the source code
in the bundle and a plist describing the frameworks that it needs. It loads
the frameworks, JIT-compiles the code, and then runs the app. Apparently this
doesn't work with the FHS layout, so Étoilé doesn't support systems that use
the FHS layout.
> If not, do you have a suggestion for a better way to improve the chances of
> GNUstep working for this fourth group.
Maybe by adding this to the end of -make's install?
echo source ${GNUSTEP_MAKEFILES}/GNUstep.sh >> /etc/profile
echo source ${GNUSTEP_MAKEFILES}/GNUstep.csh >> /etc/csh.cshrc
> One more thing to point out ... from the emails we occasionally get on the
> mailing list, it's clear that people in this fourth group exist and try
> GNUstep repeatedly until they either give up in disgust, read enough to sort
> things out themselves, or occasionally mail the rest of us for help. My
> expectation is that the ones who give up will be telling other people and
> giving GNUstep a bad reputation ... I'd like to avoid that.
Even a message at the end of installing -make telling users that they have to
add this line to their .profile would help people compiling from source.
It's worth noting that the last person we had on the list with this problem was
using Windows. Changing the default FS layout in -make does absolutely nothing
to help Windows users.
David
- Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac, (continued)
- Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac, Richard Frith-Macdonald, 2010/09/17
- Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac, Matt Rice, 2010/09/17
- Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac, Nicola Pero, 2010/09/17
- Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac, Matt Rice, 2010/09/17
- Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac, Stef Bidi, 2010/09/17
- Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac, Matt Rice, 2010/09/11
- Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac, Riccardo Mottola, 2010/09/12
- Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac, Richard Frith-Macdonald, 2010/09/16
- Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac,
David Chisnall <=
- Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac, Nicola Pero, 2010/09/16
- Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac, Richard Frith-Macdonald, 2010/09/16
- Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac, Stef Bidi, 2010/09/16
- Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac, David Chisnall, 2010/09/16
- Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac, Nicola Pero, 2010/09/17
- Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac, Yavor Doganov, 2010/09/17
- Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac, David Chisnall, 2010/09/17
- Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac, Yavor Doganov, 2010/09/17
- Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac, SPUeNTRUP - Kai Henningsen, 2010/09/18
- Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac, Yavor Doganov, 2010/09/17