Since James' recent FG work, the Qt private headers are not needed
anymore for the Qt launcher; clarify this in the comments (they are
still needed for FGQCANVAS, but it is disabled by default).
This will enable richer author meta-data in aircraft, and hence
nicer GUI presentation of author information. Client-side support
still to be added before this can be used
The qml-module-qtquick-dialogs package is needed for the built-in
launcher's Settings dialog since FlightGear commit
37dc418ce1978a55281cdedf6983e0e3ffea0108.
Forum user daweed reported[1] a nasty error[2] when doing 'git clone' or
'git pull' for FGData with the HTTPS protocol. This error disappeared as
soon as he replaced libcurl4-gnutls-dev with libcurl4-openssl-dev on his
system.
-> favor installation of libcurl4-openssl-dev over libcurl4-gnutls-dev
[1] https://forum.flightgear.org/viewtopic.php?f=20&p=329326#p329324
[2] "RPC failed; curl 56 GnuTLS recv error (-110): The TLS connection
was non-properly terminated"
Re-add the old feature, that -set.xml files can explicitly opt-out of
being included in the catalog. Useful for some development and helper /
included files in some aircraft.
Typical output of:
dpkg-query --showformat='${Status}\n' --show dctrl-tools
is:
install ok installed
(three words, not one). Thanks to wkitty42 for the report.
Rely on CMake install (in FlightGear) to copy all the required libs
to bin, so we simply grab them as part of that, instead of taking
them from the redist folder.
This relies on a corresponding FLightgear change.
Declare qtdeclarative5-private-dev and qml-module-qtquick2 as optional
dependencies, because they are needed for the built-in launcher,
starting from FG commit 3a8d3506d651b770e3173841a034e6203528f465
(committed to FG on 2017-09-26). People who can't install these packages
(oldish systems, etc.) should still be able to build and run FlightGear,
but without the built-in launcher.
See discussion around this message:
https://sourceforge.net/p/flightgear/mailman/message/36059892/
- Rename _package_alternative_inner() to _find_package_alternative() and
modify it to make it more useful when called from other functions. If
a package is found that matches one of the alternatives, its name is
printed on stdout, otherwise nothing is printed (empty output).
- Adapt _package_alternative() accordingly and rename it
to _mandatory_pkg_alternative().
- New function _optional_pkg_alternative() based on
_find_package_alternative(). Contrary to _mandatory_pkg_alternative(),
if no match is found in _optional_pkg_alternative(), a message is
printed to stdout but the script doesn't abort.
This script is designed for the following use case:
Suppose a translator has been working on a particular translation file,
and meanwhile the official XLIFF file for this translation has been
updated in FGData (new translatable strings added, obsolete strings
marked or removed, etc.). In such a case, 'fg-merge-xliff-into-xliff'
can be used to merge the translator's work into the official XLIFF
translation file. Essentially, this means that for all strings that have
the same source text, plural status, number of plural forms and of
course target language, the target texts, "approved" status and
translator comments will be taken from the first file passed in the
following command:
fg-merge-xliff-into-xliff TRANSLATOR_FILE PROJECT_FILE
Used like this, PROJECT_FILE will be updated with data from
TRANSLATOR_FILE. If you don't want to modify PROJECT_FILE, use the -o
(--output) option. If '-' is passed as argument to this option, then the
result is written to the standard output.
- Remove unnecessary imports
These imports were a leftover from early versions; now, they are done
in modules such as flightgear.meta.i18n and don't need to be in the
calling scripts anymore.
- Fix an exception message
This is a simple Python 3 script to ease rebuilding of FGData embedded
resources for FlightGear. It uses fgrcc in conjunction with
<FlightGear-repo>/src/EmbeddedResources/FGData-resources.xml and the
FGData files mentioned therein to (re)create the FGData-resources.[ch]xx
files used in the FlightGear build. The existing files in the FlightGear
repository are always overwritten (namely, FGData-resources.[ch]xx in
<FlightGear-repo>/src/EmbeddedResources).
There are command-line options (--flightgear, --fgdata and --fgrcc) to
indicate where the FlightGear and FGData repositories, as well as the
fgrcc executable can be found. However, it is most convenient to put
these paths once for all in the config file
$HOME/.fgmeta/rebuild-fgdata-embedded-resources.json (use
'rebuild-fgdata-embedded-resources --help' to see an example). This way,
you can invoke the script without any argument whenever you want to
update <FlightGear-repo>/src/EmbeddedResources/FGData-resources.[ch]xx.
This script doesn't depend on any module out of the Python standard
library (intentionally, in case distributors want to use it to recreate
themselves the FGData-resources.[ch]xx files). It should work on Python
3.5 and later versions.
Add the following files:
python3-flightgear/README-l10n.txt
python3-flightgear/fg-convert-translation-files
python3-flightgear/fg-new-translations
python3-flightgear/fg-update-translation-files
python3-flightgear/flightgear/__init__.py
python3-flightgear/flightgear/meta/__init__.py
python3-flightgear/flightgear/meta/exceptions.py
python3-flightgear/flightgear/meta/i18n.py
python3-flightgear/flightgear/meta/logging.py
python3-flightgear/flightgear/meta/misc.py
They should work on Python 3.4 and later (tested with 3.5.3). The folder
structure is chosen so that other FG support modules can insert
themselves here, and possibly be used together. I put all of these
inside 'flightgear.meta', because I don't expect them to be needed at FG
runtime (neither now nor in the future), probably not even by the CMake
build system.
To declare that a string has plural forms, simply set the attribute
'with-plural' to 'true' on the corresponding element of the default
translation (and as in Qt, use %n as a placeholder for the number that
determines which singular or plural form to use).
Assume the builds are against a version of OSG with the <fstream>
declspec(export) fix applied, and hence we can use normal linking,
not the /FORCE:MULTIPLE thing which slows down and complains.
