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


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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]