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).
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.
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/>.
- 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!
Added support for building zlib, because current openbsd-6.5's zlib is too old.
If OpenBSD:
Default to not attempting to update or download packages - for now packages
have to be installed manually with pkg_add.
Use gnugetopt.
Use ZLIB build for simgear and fgfs.
For fgfs, use -DENABLE_QT=OFF -DENABLE_FGCOM=OFF.
For run_fgfs_debug.sh, use egdb because default gdb is too old.
- make all generated scripts executable;
- use correct path for 'terragear' in the generated default config file
~/.config/TerraGear/TerraGearGUI.conf (not the 'bin' subdirectory);
- add default for the 'flightgear' path in the same file;
- don't write temporary TerraGearGUI.conf in $CBD (it's useless and
might overwrite a user-created file);
- simplify a bit (esp. using a here document for generating
run_terrageargui.sh).
So far, TerraGear was always built by d&c with
-DCMAKE_BUILD_TYPE="Debug". Following [1], d&c will now use, for
TerraGear, the build type selected with its -b option---which by default
is 'RelWithDebInfo'.
(In short: the 'Debug' build type has a very high negative performance
impact, therefore it should only be done intentionally.)
[1] https://sourceforge.net/p/flightgear/mailman/message/36650766/
- new function _depends() to allow declaring intercomponent dependencies
using a declarative style;
- declare that FGFS depends on SIMGEAR (TERRAGEAR depends on SIMGEAR as
well, but this was already there---just not in the new, declarative
style);
- print and log automatically-added components; when this happens, give
a hint about --ignore-intercomponent-deps;
- log the value of IGNORE_INTERCOMPONENT_DEPS, which reflects whether
--ignore-intercomponent-deps was used.
In Bash, the [[ <foo> == <bar> ]] and [[ <foo> = <bar> ]] conditionals
interpret <bar> as a shell globbing pattern. This wasn't desired in
_elementIn(), where the <bar> string is provided by the caller, and
might contain pattern metacharacters. Replace this conditional with a
plain string comparison made with '[' (aka, the 'test' command).
Add option --ignore-intercomponent-deps which does the following:
Ignore dependencies between components (default: don't).
Example: TERRAGEAR depends on SIMGEAR. Because of this, running
'download_and_compile.sh TERRAGEAR' would normally update, rebuild,
etc. both SIMGEAR and TERRAGEAR. Passing the
--ignore-intercomponent-deps option can be useful if you want to
update, rebuild, etc. TERRAGEAR *without* doing the same for SIMGEAR
(for instance, if you are doing repeated TERRAGEAR builds and you know
your SIMGEAR is already fine and up-to-date).
This script can be useful to debug library problems.
$ ./run_ldd.sh --help
Usage: ./run_ldd.sh LDD_ARGUMENT...
Run 'ldd' with the same LD_LIBRARY_PATH setup as done inside run_fgfs.sh.
Examples: 'run_ldd.sh fgfs', 'run_ldd.sh fgcom', etc. (this can be used
for any binary in 'install/flightgear/bin').
run_fgfs.sh and run_fgfs_debug.sh have been tested: now they work fine
when run from a directory whose path contains spaces.
The other scripts have been quickly updated, because the problems were
quite similar, but these haven't been tested (the FGo! startup script
had useless stuff, the FGx one had very weird things like "cd $ " which
probably had not been tested).
When configuring FlightGear, flightgear/CMakeModules/Translations.cmake
checks for the presence of "${FGDATA_SRC_DIR}/Translations/${xlf_file}"
where ${xlf_file} is en_US/FlightGear-Qt.xlf, however this
${FGDATA_SRC_DIR} is *not* initialized from -DFG_DATA_DIR argument
passed on FlightGear's cmake command. The autodetection only works if
FGData is located in ../fgdata from the FlightGear source directory. In
the meantime, make download_and_compile.sh explicitly pass
-DTRANSLATIONS_SRC_DIR:PATH when configuring FG.
The -DFG_DATA_DIR:PATH vs. -DFG_DATA_DIR change is visible in
build/flightgear/CMakeCache.txt but not decisive here.
Should behave better in case one of these variables contains whitespace.
Note: I didn't look inside the generated scripts such as run_fgfs.sh,
they may have similar issues.
For instance, don't attempt to install TerraGear dependencies unless
TERRAGEAR is in WHATTOBUILD. This should significantly reduce the number
of packages downloaded by the first use of download_and_compile.sh that
doesn't have -pn in the options.
We may get reports of missing dependencies for some components as a side
effect of this change; we'll just have to add the missing dependencies
wherever they are required (this can happen if, for instance, some
particular dependency was so far listed in the comments only as a
TERRAGEAR dependency, but was actually required by *another component*
such as FGFS). Incorrect dependency information needs to be fixed,
that's all there is to it.
The dependency is optional because CppUnit is shipped with the FG
sources. However, when installed via the distro package manager as we
are attempting here:
- the FG build will be quicker;
- libcppunit-dev will be updated like other distro packages (e.g.,
it will receive security updates).
