* Curtis Olson -- Friday 30 January 2009:
> On Fri, Jan 30, 2009 at 12:59 PM, Melchior FRANZ <mfr...@aon.at> wrote:
> Wow, I'm sorry if I caught you on a bad day.
This was a good day! Until someone reported once again how he ran into
this stupid ambiguity, and someone else posted a broken "fix". And it
won't be the last time that this happens.
> A design goal of flightgear has always been to keep
> itself contained in one area and be a good citizen of your hard drive.
This assumption suggests a badly laid out file hierarchy. It's tailored
for FlightGear developers who throw source and data in the same location.
But on Unix platform-independent data belong to /usr/{local/}share/
while source is in /usr/{local/}src/ or in someone's HOME or a project
dir. And Linux distributions follow this rule. They put data in
/usr/share/FlightGear/ (or, shudder, in /usr/share/games/...).
The reason for this separation is that platform independent data can
be put on read-only mounted partitions and be shared across several
machines via NFS. Source must be editable.
What's wrong with defining the following on your machine? You'll
probably be the only who does it, but that's fine. :-}
export FG_SOURCE=/wherever
export FG_ROOT=$FG_SOURCE/data
> A person could have several FG_ROOT's on their hard drive corresponding to a
> stable version, a development version, or some other version (perhaps a
> version that talks to some other software you need.)
You can also have that with FG_ROOT and FG_SOURCE, or whatever layout
you prefer.
> Recall that we don't require (and actually recommend against) putting add on
> scenery inside the data tree.
True, and we have FG_SCENERY for that. And it points to where the
scenery is, not to a directory which contains a data/ directory
which contains the scenery. ;-)
> Despite the name calling, it is inconsistency that bites us.
Which name calling? It's the ambiguity that bites us, and lots
of people who don't understand it. And why should they? There
shouldn't be an ambiguity in the first place.
> > My intention is to remove the disgusting hack that checks for
> > an existing data/ dir and that appends it if found, and that
> > before the 2.0 release.
>
> IMHO, this is moving in the wrong direction to fix the inconsistency.
So what do you suggest? That FG_ROOT must always point to a
directory containing a directory named "data/" which contains
the data? Or shall we rename FG_ROOT to FG_DATA, and let
FG_ROOT point to the source, and FG_DATA to the data? In any
case, there should be no assumption that data is in the source
directory. It doesn't belong there.
> I think I already explained my thoughts in terms of logical
> consistency, but I'm sure you are asking for a reason you like,
> so I won't even attempt that.
This would be defeat and an admission that there is no reason at
all. But actually you gave one: having several source/data
conglomerates. I just don't think that this justifies the
ambiguity and the regular confusion. We can do better than that.
m.
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
