The typo was introduced in 7e607b8403 from July
2016. The result was a series of alert messages such as:
savexml: writing to 'Path "/flightgear/home/.fgfs/runtime-jetways/0.xml"' denied
(unauthorized directory - authorization no longer follows symlinks)
This allows the sources and headers in src/Main/ to be used by other targets.
They are grouped into the new "Main" flightgear component via the macro in the
FlightGearComponent CMake module. The bootstrap.cxx file with its main function
has been separated out into a separate variable MAIN_SOURCE for use by the fgfs
binary.
All these files have therefore been removed from the test_suite CMakeLists.txt
file, as they are added via FG_SOURCES and FG_HEADERS. The MSVC grouping code
also does not need to deal with the now deleted separate SOURCE and HEADER
variables for these files.
This is for simplifying the main src/Main/CMakeLists.txt file and allowing the
code to be shared with the test suite.
The generated source and header files have also been removed from the main
source list and placed in the CMake module as the global variables
EMBEDDED_RESOURCE_SOURCES and EMBEDDED_RESOURCE_HEADERS.
New methods Addon::createStorageDir() and Addon::getStoragePath() with
corresponding Nasal bindings in the addons.Addon ghost:
createStorageDir() method (returns the dir, doesn't fail if it already
exists)
storagePath read-only attribute to get the dir
The directory reserved for each add-on is
$FG_HOME/Export/Addons/ADDON_ID, but please use the above methods (or
the corresponding C++ ones) to avoid hardcoding such paths in your code.
Also create directory $FG_HOME/Export/Addons in fgInitConfig() as a way
of reserving the namespace, in order to prevent future failures in case
someone would have the strange idea to create it as a file...
If an add-on has a file named addon-menubar-items.xml in its base
directory, load it and add its items to the FG menubar.
Logically, fgStartNewReset() should call
flightgear::addons::AddonManager::instance()->addAddonMenusToFGMenubar()
in order to re-add the items, however doing so would cause the
add-on-specific menus to be added one more time on every reset, because
for some reason, commit 45ea8b5daa added
the PRESERVE attribute to /sim/menubar (apparently to preserve the state
of menu entries upon reset?).
Note: the addon-menubar-items.xml files are reloaded during reset,
however the menu bar doesn't reflect this, since adding the
reloaded items to the menu bar in fgStartNewReset() would cause
the add-on-specific menus to appear several times in the menu bar,
as explained above.
The add-on framework now uses the following files in each add-on
directory:
- addon-config.xml (previously: config.xml)
- addon-main.nas (previously: main.nas)
This is consistent with the addon-metadata.xml file that is already part
of the interface between FG core and add-ons. The goal is to make it
clearer, when browsing an add-on directory, which files belong to the
"FG core <-> add-on" interface and which files belong to the add-on
proper. This will be beneficial also when more files are added to the
"FG core <-> add-on" interface, such as possibly addon-events.xml in the
future.
This change is incompatible, thus it is the right time to do *before*
2018.2.1 is out, especially considering that this upcoming release
already has incompatible changes in the add-on API, namely the
requirement of the addon-metadata.xml file and the type of the argument
passed to each add-on's main() function. We'll try harder not to break
compatibility in the add-on API once 2018.2.1 is out. For now, it is
still a good time to try to get the API as clean as possible.
If running with the launcher, and FG-home is read-only, show a warning
to the user, since this is probably a surprise to them.
(In non-launcher mode we don’t show the box, since it’s more likely to
be an intentional duplicate launch)
This makes it possible to look up files from add-on directories using
for instance FGGlobals::resolve_resource_path(), passing a string such
as "[addon=ADDON_ID]relative/path" as explained in the previous commit.
This commit adds C++ classes for add-on management, most notably
AddonManager, Addon and AddonVersion. The AddonManager is used to
register add-ons. It relies on an std::map<std::string, AddonRef> to
hold the metadata of each registered add-on (keys of the std::map are
add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>).
Accessor methods are available for:
- retrieving the list of registered or loaded add-ons (terminology
explained in $FG_ROOT/Docs/README.add-ons);
- checking if a particular add-on has already been registered or
loaded;
- for each add-on, obtaining an Addon instance which can be queried
for its name, id, version, base path, the minimum and maximum
FlightGear versions it requires, its base node in the Property Tree,
its order in the load sequence, short and long description strings,
home page, etc.
The most important metadata is made accessible in the Property Tree
under /addons/by-id/<addon-id> and the property
/addons/by-id/<addon-id>/loaded can be checked or listened to, in
order to determine when a particular add-on is loaded. There is also a
Nasal interface to access add-on metadata in a convenient way.
In order to provide this metadata, each add-on must from now on have in
its base directory a file called 'addon-metadata.xml'.
All this is documented in much more detail in
$FG_ROOT/Docs/README.add-ons.
Mailing-list discussion:
https://sourceforge.net/p/flightgear/mailman/message/36146017/
Several checks were off by one, resulting in a segfault when only one
parameter was missing.
Also improve error messages, giving details about what is expected.
Doing the option processing in Options::parseOption() has drawbacks:
- doesn't work well upon reset;
- doesn't work in the built-in launcher Additional Settings box.
Options::processOptions() is invoked both upon reset after the property
tree has been reset, and by the built-in launcher to process options
given in the Additional Settings box. This is not the case of
Options::parseOption() which is better for... parsing. :-)
Also use SGPath::fromLocal8Bit() to decode the path argument of --addon.
Rewrite the position-init code for carrier starts, to precisely wait
on the carrier model being loaded, before proceeding with FDM init.
This allows the FDM to see the correct carrier model in the ground
cache, and hence avoids starting in the water.
To implement this, the CheckSceneryVisitor is used to force the carrier
model to be loaded while the splash-screen is visible.
The bug fix is:
- if (!log.output) {
+ if ( !(*log.output) ) {
(i.e., testing the sg_ofstream instance instead of its address) and then
ensuring that the corresponding Log instance is removed from _logs and
destroyed.
The "destroy" part is made automatic by using std::unique_ptr instead of
raw pointers. This allows to simplify several areas of the code.
Don't provide custom definitions for the constructor and destructor of
FGLogger anymore, now that they don't need to do anything: IIRC, this
allows compilers to do some optimizations according to the C++ standard.
Since the paths of files overwritten by FGLogger come from the property
tree[1], they must be validated before we decide to write to these
files.
[1] Except for the "empty" case, which uses the default name
'fg_log.csv'. This file is deemed acceptable to overwrite in the
current directory, as the name is completely fixed and clearly
FG-specific.
Call fgInitAllowedPaths() right after Options::processOptions() (which,
among other things, determines $FG_ROOT and processes
--allow-nasal-read). This way, fgInitAllowedPaths() can be used in much
more code, such as when initializing subsystems.
using --addon=/foo/bar does
* add /foo/bar/config.xml as propertyfile
* add /foo/bar to aircraft_paths to provide read-access
* sets property /addons/addon[n]/path = "/foo/bar"
* addons get initialized from addons.nas in FGDATA/Nasal
Change fgcommand to take an optional property tree root element.
This fixes the animation bindings to use the defined property tree root - to support multiplayer (or other) model that can bind to the correct part of the property tree.
Requires a corresponding fix in sg to allow the command methods to take an optional root parameter.
What this means is that when inside someone else's multiplayer model (e.g. backseat, or co-pilot), the multipalyer (AI) model will correctly modify properties inside the correct part of the property tree inside (/ai), rather than modifying the properties inside the same part of the tree as the non-ai model.
This means that a properly setup model will operate within it's own space in the property tree; and permit more generic multiplayer code to be written.
This is probably responsible for some of the pollution of the root property tree with MP aircraft properties.
This adds console and message-box warnings, based upon aircraft
declaring the minimum FG version they support. A follow-up commit
will extend the launcher UI to warn the user about this in a nicer
way.
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.
When building with MSVC, use the CMAKE_MSVCIDE_RUN_PATH variable to
prepend ${MSVC_3RDPARTY_ROOT}/${MSVC_3RDPARTY_DIR}/bin to the PATH in
order to (hopefully) allow fgrcc to find the libraries it needs. We may
need to add something similar for SimGear---will see.
The use of CMAKE_MSVCIDE_RUN_PATH and other ways to address this problem
are discussed at
<https://stackoverflow.com/questions/28533012/how-to-set-runtime-path-for-cmake-custom-command-on-windows>.
${CMAKE_SOURCE_DIR}/src/EmbeddedResources/FlightGear-resources.xml
(currently empty) is automatically "compiled" into
${CMAKE_BINARY_DIR}/src/EmbeddedResources/FlightGear-resources.[ch]xx by
fgrcc inside the build directory. These files are incorporated into the
FlightGear build (FlightGear-resources.cxx is linked into FlightGear).
When the XML embedded resource declaration file added here,
FlightGear-resources.xml, is compiled, fgrcc is passed the
--root=${CMAKE_SOURCE_DIR} option, so that files referred to in
FlightGear-resources.xml are looked up relatively to the root directory
of the FlightGear repository. One could use a second XML embedded
resource declaration file compiled with a different --root option to
grab files from FGData, for instance. I would name such a file
FGData-resources.xml to be consistent with the current naming scheme.
Note: this --root option applies to the paths of real files. Don't
confuse it with the 'prefix' attribute of <qresource> elements
inside XML resource declaration files (such as
FlightGear-resources.xml), which applies to the virtual path of
each resource defined beneath.
The commands in src/Main/CMakeLists.txt ensure that
FlightGear-resources.xml is recompiled with fgrcc whenever it is
changed, and obviously also when FlightGear-resources.cxx or
FlightGear-resources.hxx is missing. However, CMake doesn't know how to
parse fgrcc XML resource declaration files, therefore when a resource is
modified but the XML file it is declared in is not (here,
FlightGear-resources.xml), you have to trigger yourself a recompilation
of the XML resource declaration file to see the new resource contents
inside FlightGear. The easiest ways to do so are:
- either update the timestamp of the XML resource declaration file;
- or remove one or both of the generated files
(FlightGear-resources.cxx and FlightGear-resources.hxx here).
The EmbeddedResourceManager is created in fgMainInit() just after
Options::processOptions() set the language that was either requested by
the user or obtained from the system (locales). Resources from
FlightGear-resources.cxx are added to it, after which
EmbeddedResourceManager::selectLocale() is called with the user's
preferred locale (obtained with FGLocale::getPreferredLanguage()).
Upon reset (fgStartNewReset()), EmbeddedResourceManager::selectLocale()
is called in a similar way after Options::processOptions(), however in
this case the EmbeddedResourceManager instance doesn't have to be
recreated.
- remove use of boost in src/Main/locale.cxx;
- add missing header <cstring> for std::strlen();
- replace NULL with nullptr;
- fix some broken indentation;
- other small readability improvements.
This function returns the preferred "locale"[1] according to user choice
and/or settings (i.e., it is influenced by --language if passed,
otherwise by current locale/system settings). The return value never has
an encoding part. It is the empty string if nothing could be found,
otherwise should look like fr_BE or it_IT.
[1] "language" term used in the function name for consistency with the
existing and related FGLocale::selectLanguage().
Windows and Mac implementations return a string without any encoding
specifier -> remove this specifier directly in the Unix/Linux
implementation for consistency.
Also do some small refactoring with the new static method
FGLocale::removeEncodingPart(). Slight difference with the previous
algorithm: if a '.' is found in the given locale spec, we assert() that
it is not the first character. The previous code in
FGLocale::findLocaleNode() used to consider such weird locale specs
starting with a dot as normal locale specs without any encoding part.
Note: the same change could be done where FGLocale::findLocaleNode()
looks for an underscore in order to prepare for the fallback
search (e.g., 'fr' after not finding translations for 'fr_FR').
Print an error message and exit if --{enable,disable}-enhanced-lighting
or --adf are used (those deprecated options will be removed in a future
version of FlightGear).
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.
