On Fri, Jan 30, 2009 at 12:59 PM, Melchior FRANZ <mfranz@aon.at> wrote:
* someone off list, but IMHO this should be discussed openly:

> [...] but the intent is for FG_ROOT to point to a top level
> directory (i.e. the root) and beneath that would be bin/
> data/ src/ lib/ include/ etc ....

Wow, I'm sorry if I caught you on a bad day.  I can't deal with a big flame war this afternoon, maybe we can find a way to discuss this issue in less apocalyptic terms?
There's only one reason why we need to point fgfs and associated
scripts and tools to some place *at all* (using FG_ROOT or --fg-root):
So that they can find the data at runtime. There's no reason
*whatsoever* to have a pointer to source files and #includes.

Structurally, my view of "root" is that it should point to the top of a relocatable tree.  A design goal of flightgear has always been to keep itself contained in one area and be a good citizen of your hard drive.  So in my view, the "root" directory would contain things like the binaries subdir, the data subdir, the scenery subdir, possibly external aircraft subdir, and possibly the source code that corresponds to this version.  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.)

Recall that we don't require (and actually recommend against) putting add on scenery inside the data tree.
And the runtime data directory is that which contains file
"version". It's *not* a directory which contains a data/ directory
which contains the data.

Making the layout optional was a bad idea 10 years ago, and it
is a bad idea today. Even worse, as we have many more users
and it bites us a lot more often in the ass than it used to.

Despite the name calling, it is inconsistency that bites us.
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.
I'm not an archeologist, and I don't think we should look at what
seemed to make sense a decade ago. What we have now doesn't make
sense. It leads to bugs and confusion, while not having a *single*
advantage. Or could anyone tell me one, please? Just one?

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. :-)

Curtis Olson: http://baron.flightgear.org/~curt/