For SimGear, FlightGear and FGData (i.e., the SIMGEAR, FGFS and DATA
components in download_and_compile.sh-speak), option --lts now means
release/2020.3 and the new option --old-lts means release/2018.3.
Each of these options may be passed multiple times. The advantage over
the previous interface (environment variables SG_CMAKEARGS and
FG_CMAKEARGS) is that the new interface allows one to pass arguments
containing spaces to CMake, for instance:
--sg-cmake-args='-DCMAKE_CXX_FLAGS=-Wno-deprecated-declarations -Wall'
(the single quotes here would be interpreted by the user's shell, and
removed before download_and_compile.sh can see them). Setting the
environment variables SG_CMAKEARGS and FG_CMAKEARGS should still work as
before but is now deprecated.
The implementation uses Bash arrays named SG_CMAKE_ARGS and
FG_CMAKE_ARGS, but in order to avoid confusing users about the
deprecated variable names, the log file continues to print
'SG_CMAKEARGS=...' and 'FG_CMAKEARGS=...' (note the different use of
underscores in the names).
aircraft_updates.py - list updated aircraft in fgaddon between two date
points. Useful for release notes.
find_md5file.py - identify identical files based on md5sum. Useful
for finding license infringement.
Before this change, using OSG with download_and_compile.sh several times
in the same directory would fail because the upstream repo for OSG has
none of README, README.txt and README.rst at top-level (it has a
README.md). Testing for the .git dir is definitely more reliable.
If --cleanup is used and no component has been specified on the command
line, run the cleanup routine but don't process any component: no
download, no compilation, no installation. Previously(*), this used to
process the default set of components: SIMGEAR FGFS and DATA.
Therefore, if all you want to do is to remove compiled and installed
files, you can now run:
download_and_compile.sh --cleanup
(*) During less than 24 hours, as --cleanup was added yesterday.
Move several chunks of code to their own function. This will make the
code easier to follow when largish chunks are executed only under
certain conditions.
Minor changes unrelated to the refactoring:
- make _logSep print a larger separator (78 chars);
- write the SELECTED_SUITE at the top of the log file.
_gitUpdate() used to call 'git pull' then 'git checkout'. If the latter
command really did a branch switch, this could leave the local branch
behind its remote counterpart (that was hopefully fetched by the
'git pull'). From now on, we do:
git fetch origin
git checkout --force "$branch"
git pull --rebase
(the --force option was already there before in the form of -f). This
way, we can be sure that the local branch we check out is up-to-date
when the function returns.
Also replace short options by long ones for better readability of the
code, and use Bash's [[ ... ]] conditional construct instead of [ ... ]
for more efficiency---I think.
Note: 'git stash save' is documented as deprecated in favor of
'git stash push', however the latter appears to have been
introduced in 2017, therefore I believe it is too early to use it
in download_and_compile.sh.
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.
