This is a headless mode, designed to be invoked from an installer, not
used directly by users. It doesn’t touch the ‘normal’ installation, but
rather removes the other files FG typically creates or downloads.
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/>.
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.)
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.
- Use setlocale() to ensure consistent handling of locales and
string handling irrespective of whether or not QCoreApplication
is invoked. Forces a the C locale for numerics and collation,
since many pieces of FG assume this.
* make --enable-fpe work on Linux and MSVC
* standardise the code paths for different platforms
* add an argument finding helper to Options
(This is a basic cleanup, contributions from people with
more experience in this area are welcome)
This allows us to display a platform-native dialog for problems
which occur early in startup (before we can show a PUI/Canvas dialog).
In particular this improves feedback where FG_HOME, FG_DATA or
aircraft selection is wrong, all of which happen very early in startup.
- Point the homedir variable to %APPDATA%/flightgear.org. This
enables .fgfsrc in this path for windows users.
- Evaluate the returncode of gethostname() to not strdup() bogus
characters on failure. Also mainly on windows.
