When doing the 'git ls-remote' request to find the latest FG release,
d&c was using a hardcoded address for the FG repo. Use
${REPO_ADDRESS[FGFS]} instead.
Only those components present in WHATTOBUILD are really interesting when
printing and logging COMPONENT_BRANCH[foo]=bar. Inter-component deps are
taken into account before doing that, since they may add components to
WHATTOBUILD.
Option --lts builds the latest LTS release of components SIMGEAR, FGFS
and DATA. The presence of option -s or --lts affects the version or
branch checked out for each component; however, passing none of these
options doesn't imply that development versions will be used for
everything---this selects development versions for FlightGear and
possibly closely-related software, but for the rest, we aim at something
reasonably usable, as in "current release".
For each component, the default version selected depending on whether
-s, --lts or none of these was given, can be overridden using
'--component-branch COMPONENT=BRANCH' (without the quotes). For
instance:
download_and_compile.sh --lts \
--component-branch OSG=OpenSceneGraph-3.6 SIMGEAR FGFS DATA OSG
will build the latest LTS release of FlightGear against the
OpenSceneGraph-3.6 branch of OpenSceneGraph. Option --component-branch
may be used several times and always overrides the defaults determined
by the presence or absence of -s or -lts. Thus, the relative order of
-s, --lts and --component-branch options does not matter.
This commit also adds text to the standard output and log file that
tells users:
- which "suite" they have selected (default=next, -s or --lts) and
what this implies;
- which branch will be checked out for each component (i.e., after
the overrides from all --component-branch options passed have been
applied).
It is nonsensical to provide both -s and --lts in the same invocation,
but the last one wins.
- Move test_catalog.py, test_sgprops.py and catalog/testData/ to
python3-flightgear/flightgear/meta/tests/.
- Copy catalog/fgaddon-catalog/ to the same place (it is needed by
test_catalog.py).
- Adapt test_catalog.py and test_sgprops.py accordingly.
- Remove the executable bits from test_catalog.py and test_sgprops.py:
this is because test_catalog.py can't be run directly anymore; well,
it can but 3 tests would fail in this setup. No time to investigate
why (sorry), but this commit adds a README.txt in
python3-flightgear/flightgear/meta/tests/README.txt that explains how
to run the tests in a way that works (basically, run
'python3 -m unittest' from the python3-flightgear directory).
For a bit more context, see
<https://sourceforge.net/p/flightgear/mailman/message/37042247/>.
Also add a README.md to python3-flightgear explaining how to use the
PYTHONPATH environment variable or a .pth file in order to run the
Python scripts in FGMeta, and pointing to the top-level directories
'catalog' and 'i18n'.
- Move the support modules inside python3-flightgear/flightgear/ and
remove their shebang, if any.
- Accordingly adapt the import statements.
- Change shebangs from e.g. '#! /usr/bin/python' to
'#! /usr/bin/env python3'.
- Small changes to make Python 3 happy with all scripts.
catalog/check_aircraft.py should be run under Python 3 from now on.
- Use the new flightgear.meta.strutils.simplify() function.
- Automatically add a comment to the generated file to indicate that it
was automatically generated and shouldn't be manually modified, etc.
- Improve error handling: abort with a clear error message if any of the
'id', 'name' and 'desc' children of a 'scenario' element is
problematic (empty or missing, for instance).
- Rename make_xml_leaf() to makeXmlLeaf() + other minor renaming.
I believe the problematic code could only be reached when reading buggy
versions (i.e., with duplicate ids) of the legacy FlightGear XML
non-master l10n files, which is why we haven't tripped on it so far.
Introduce a BASIC_CATEGORIES variable at the top of
python3-flightgear/flightgear/meta/i18n.py that lists all categories
handled by BasicL10NResourceManager. Since currently all of our
translation files can be handled this way (the XML master files all have
a flat structure), we only need to say BASIC_CATEGORIES = CATEGORIES.
With this change, adding a new basic category such as
'weather-scenarios' only requires one to add it to CATEGORIES.
Because cloning FGData from SourceForge using https does not work (this
has been the case for *years*) whereas normal updates of an existing
clone do work, and so does cloning the repository from its official
GitLab mirror using https, this commits implements a special case in
_gitDownload():
If the assembled clone URL is
<https://git.code.sf.net/p/flightgear/fgdata>, then ask the user if he
agrees to automatically clone FGData from GitLab and arrange the
repository setup to fetch subsequent updates from SourceForge. This
should be fine because <https://gitlab.com/flightgear/fgdata> is an
official mirror of FGData. The default answer is thus to do so. It is
automatically chosen when download_and_compile.sh is called with
--non-interactive (new option).
This implies that the initial use of download_and_compile.sh is again as
easy as subsequent ones.
This commits also adds the utility function _yes_no_quit_prompt() to
repeatedly ask a question ($1) until a valid answer has been provided.
The function automatically uses the default answer ($2) if
--non-interactive has been passed to download_and_compile.sh. See the
“discussion” at
<https://sourceforge.net/p/flightgear/mailman/message/37017469/>.
- Add class method availableTranslations() to AbstractFormatHandler in
i18n.py.
- Use it in fg-update-translation-files to allow autodetection of the
available translations when no LANGUAGE_CODE is passed to
fg-update-translation-files.
This should address James' wish at
<https://sourceforge.net/p/flightgear/mailman/message/37003967/>.
- The old URL for CMake's Git repository doesn't support https anymore;
update it to match the one given at <https://cmake.org/>.
- Build the 'release' branch rather than 'master':
download_and_compile.sh is not meant for CMake hackers!
