* Curtis Olson -- Friday 30 January 2009: > The traditional unix scheme, and most linux packaging schemes, assume only > one version of the software at one time. [...] > How about running a "live" version off a CD?
I don't see the problem. There's one executable, which you start like any other executable: you put it in the PATH or specify the full address. And you tell it which data to use. Mandating that both be thrown into the same directory doesn't really solve any problem. But I'm fine with all the throwing together, as long as I'm not forced to do that as well. What is just bad design is that the data directory is not really defined. It can be under $FG_ROOT or $FG_ROOT/data. And all utilities have to know about this ambiguity and also test for both. Or they don't, and we get the bug reports. It's just unclean, bad design. None of the utilities, be it atlas, fgsd, fgrun or any of the scripts, is actually interested in the build/install dir. All of them only want to know where the data is. Nothing is really interested in your vision of FG_ROOT. It's just something that you use on your machine (if at all :-). > > Which name calling? > But I do understand your tone if you are assuming that question > always == attack. I didn't understand the question as attack. But I see a notorious problem, and how all attempts to fix it have been shot down so far. And I'm annoyed if someone accuses me of "name calling" when there was none. I only called the data/ hack ugly and disgusting. In this part of the world code doesn't count as a person. But I'd be willing to apologize to the hack if it feels insulted. (Not that this would make it less ugly, of course.) :-p > I personally would like to see FG_ROOT point to a top level directory that > could contain an entire FlightGear installation. Below that we would have > sensible defaults ... like data/ bin/ scenery/ but these could be overridden > with FG_DATA FG_SCENERY FG_AIRCRAFT, etc. OK, fine with me. Then let's rename fgfs' --fg-root to --fg-data, and let it read FG_DATA rather than FG_ROOT. Someone has to adapt all the utilities, as none of them, be it atlas, fgsd, fgrun, fgadmin or any of the many scripts are interested in the path to the build/install dir. Any of the applications are only interested in FG_DATA. And please not again a fallback from FG_DATA to FG_ROOT/data, because that just repeats that old mistake. fgfs needs runtime data, so tell it where it is. Period. If you don't, then it won't work. Just like it doesn't work if there's no preferences.xml or no version file. > Melchior, I simply asked you a question based on your CVS commit log > messages and explained my perspective. You immediately spun this around to > the list implying I don't like open discussion. [...] > What probably needs to happen is a bit more open discussion, Intended irony? ;-) 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
