This option recursively deletes build and install directories, but
preserves FGData if present (FGData is in
<base_dir>/install/flightgear/fgdata, hence the need to take special
care of it).
There is currently no way to trigger this cleanup routine whithout
pretending to act on at least one component, since "no components
specified" implies "SIMGEAR FGFS DATA". That said, using -pn -dn -rn -cn
with one of the components you already have should be close enough to
"only do the cleanup".
This improves readability a little bit. set_ld_library_path was defined
but unused since commit a5e4c47f. Note that this variable must be set
*after* the OpenBSD-specific code block because its definition relies on
the value of 'paths', which is modified in said block.
This ensures that users building 'next' have seen the message that warns
about possible instability and are aware of the other options (--lts for
the latest Long Term Support release, -s for the latest release).
The default answer is to continue. If --non-interactive has been given,
the prompt is skipped and download_and_compile.sh proceeds as usual.
This commit also adds _yes_no_prompt() which makes more sense than
_yes_no_quit_prompt() here, since the 'no' answer implies that the user
wants to quit.
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!
