The options.cxx code is not ready to handle recursive use of --config
(for config files). Instead of failing in an ugly way, abort with a
clear error message in such situations. See discussion at
<https://sourceforge.net/p/flightgear/mailman/message/35838852/>.
Note: it *is* possible to load XML PropertyList files from config files,
so --config is not entirely "banned" from config files.
+ add missing include
This has the advantage, according to my testing on Linux, that core
files obtained after a crash now point to the crashing thread again,
when one starts 'gdb' on the core file and runs the 'bt' command.
Apparently, when using kill(), the signal is seen as coming from the
outside and gdb's 'bt' command points to the wrong thread in general
when debugging using a core file (when debugging "live", gdb intercepts
the signal even before FG's signal handler is started).
See discussion starting at
<https://sourceforge.net/p/flightgear/mailman/message/35833221/>.
Before SimGear commit a962c90b30f36575d01162b64471fa77473237a0,
SGPath::pathListSep was a char in static memory that was not necessarily
followed by '\0'. As a consequence, using &SGPath::pathListSep as a
C-style string could result in a string containing the correct separator
*plus* whatever followed in memory until the first null byte...
SimGear commit a962c90b30 changes this situation by making
SGPath::pathListSep an array of two const chars: the path list separator
followed by a '\0'.
This commit simply adapts FlightGear to this change, which fixes a
couple of bugs where the separator was used, mainly unneeded NavCache
rebuilds due to the "apt.dat", "fix.dat" and "nav.dat" properties in the
SQLite database containing the correct paths separated by a possibly
incorrect separator string (there was no alteration of the cache
contents as far as I can tell, since the db property is only used to
check if the lists of apt.dat, fix.dat and nav.dat files have changed).
Code and tests to demonstrate migrating of older auto-save files, with
blacklisting support to exclude properties. Disabled pending agreement
on the required blacklisting values.
Some pieces of code such as fgMainInit() and, by cascading effect,
fgInitHome(), were careful to return a meaningful value indicating
success or error, however the main() function in src/Main/bootstrap.cxx
ignored it royally so far.
main() now returns:
- EXIT_FAILURE if fgMainInit() or fgviewerMain() throws an exception;
- whatever said function returns otherwise.
- Rename fatalMessageBox() to fatalMessageBoxWithoutExit(). This should
prevent the kind of bug that prompted this set of changes: someone
calling fatalMessageBox(), assuming the program would stop at that
point, whereas in reality it did not.
- Add new function fatalMessageBoxThenExit(). This is not vital of
course, but allows one to spare one line here and there and to apply
the DRY principle for such fatal exits.
- Replace every existing call to fatalMessageBox() with one or the other
of the two new functions. Improve formatting along the way. This
fixes a few bugs of the kind explained above.
Basically, this is because fatalMessageBox() is only safe to call from
the GUI thread, however it seems fg_terminate() can be called from any
thread (according to C++11 semantics). Additionally, fatalMessageBox()
typically requires some work to happen in the GUI thread (event loop) in
order to display something, but we can't realistically expect this while
running a terminate handler just before the program dies.
See messages around
<https://sourceforge.net/p/flightgear/mailman/message/35775803/> for a
discussion of this subject.
+ Minor header cleanup (<locale.h> replaced with <clocale>, etc.)
We probably need a warning for cross-aircraft paths, but leaving that
for a separate change since I’m worried it will warn on MP aircraft.
Maybe better checked in the Python scripts than in the app?
Compile a useful subset of FG as a shared library, and add two basic
uses of this to exercise some Flightplan / RoutePath / navaid
functions.
The test framework can/will be expanded incrementally from here, this
is just a starting point.
As part of this, add the ability to distinguish default vs explicit
airport selection via a new /sim/presets/airport-requested flag. This
enables us to more cleanly handle different combinations of startup,
especially the case where the user requests an airport but no runway
(wants auto selection), ensuring we don’t look for the default airport’s
runway (from location-presets.xml) in that case.
- Declare 'datTypeStr' and 'defaultDatFile' as public member variables
of NavDataCache ('defaultDatFile' is not *required* for this commit,
it just seems to make sense to treat both members the same way/keep
them together in the source code).
- New keys under "navigation data" in the JSON report: "fix.dat files"
and "nav.dat files".
Make a single Cmake value to expose the build type to code, and use
this to default a run-time ‘developer-mode’ property, which can be
over-ridden from the command line.
Use this to drive the different warning levels. Policies subject to
review, especially whether nightly builds should default to
developer mode or not.
Uses TTF fonts, and displays more information textually including
the application version and current aircraft.
Also rename FGRenderer::splashinit to preinit, as was suggested
a long time ago.
This change is the logical counterpart of SimGear's change from commit
79f869a7f32910197be72b21f6489fbbba02c836 that moved the following files
from simgear/misc to simgear/io/iostreams:
gzcontainerfile.cxx
gzcontainerfile.hxx
gzfstream.cxx (formerly zfstream.cxx)
gzfstream.hxx (formerly zfstream.hxx)
sgstream.cxx
sgstream.hxx
sgstream_test.cxx
Each argument creates another log file, in the directory named. Symbolic
value ‘desktop’ creates logs on the user’s desktop.
Needs corresponding SimGear commit to build
For unknown reasons this seems to alleviate the word-wrap / min-height
bug on Windows. Committing so we can test and verify this is really
the case before the next release.
Requires FGData commit: 0565eaab10a5d466cd485766b17d1870936a0a57
(which actually renames the file).
Also disables the preferences-load command since I don’t believe it
would actually be safe to reload the defaults without doing a simulator
reset (aircraft -set.xml values would be overwritten, for example)
As discussed on the devel list, only require the major+minor versions
of FG+SG+data to match by default. If we encounter a situation on
a release branch where stronger checks are needed, it’s easy to
restore.
