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).
- When -pn has been passed (i.e., the user wants the 'apt-get install'
step to be skipped), don't waste time checking the available
dependencies. Rationale: someone using -pn has probably already
installed the required packages either manually or during a previous
run of download_and_compile.sh, and anything missing couldn't be fixed
under -pn regime anyway, by definition. Assume that users passing -pn
want to build with the packages they already have, and let them spare
some time and CPU cycles.
- New options --package-manager and --sudo. The former defaults to
'apt-get' as usual, but 'aptitude' can be used as well. The --sudo
option specifies the sudo-like program to use. Passing --sudo=echo
allows one to see the apt-get or aptitude commands without running
them. Passing --sudo= or --sudo="" (i.e., giving an empty value)
causes the package manager to be called directly, without any
intermediate sudo-like program.
- The PKG variable is now a Bash array, which is a bit cleaner and
blends better with the new, array-based implementations of
_aptUpdate() and _aptInstall() (whose purpose is to allow the
newly-added flexibility without multiplying the code paths).
qtbase5-dev-tools contains the 'rcc' tool, and qttools5-dev-tools
contains 'lrelease'. Unless I'm mistaken, both are needed to compile the
Qt resources containing translations in the QM format for FlightGear's
built-in launcher.
The "DIRECTORY=..." was printed too late in the log file (after the apt
stuff). Fix that and make some code a bit easier to follow (e.g.,
LOGFILE is assigned only once now).
Introduce a new function _log() that allows one to factor out the
remaining explicit appends to $LOGFILE. Summary:
_log writes its arguments to $LOGFILE
_printLog ditto, and also prints them to the terminal
_logOutput echoes its standard input to the terminal and/or to $LOGFILE
(depending on its first argument). Typically used in the
last component of a pipeline.
Use this function for all commands that produce output we want to see on
the terminal and in the log file. Actually, the first parmeter of the
function, which is optional, allows one to choose where we want the
output to be written to: the terminal and/or the log file (three
possibilities, since for none of these, '>/dev/null' redirection can be
used directly).
Fix for commit 8a7fd33b2b: in argument to --git-clone-site-params,
take the username exactly as provided instead of converting it to
lowercase (the site and protocol are still converted to lowercase, but
*that* is intentional).
This commit adds two new options:
--git-clone-default-proto=PROTO
Default protocol to use for 'git clone' ('ssh', 'https' or git'). If
the option is not specified, the default is still 'https'.
--git-clone-site-params=SITE=PROTOCOL[:USERNAME]
Connect as USERNAME with PROTOCOL when cloning a Git repository hosted
at SITE (sample sites: 'SourceForge', 'GitHub'; valid protocols:
'ssh', 'https' and git'). USERNAME is required when using the 'ssh'
protocol. The hosting site and protocol are matched in a
case-insensitive way.
This option may be passed several times with different sites, e.g.
download_and_compile.sh --git-clone-default-proto=ssh \
--git-clone-site-params SourceForge=ssh:frougon \
--git-clone-site-params=GitHub=https
(replace 'frougon' with your username at SourceForge)
For repositories located at a hosting site specified with
--git-clone-site-params, the protocol indicated with this option
overrides the default protocol, be it the script default or the one
given with --git-clone-default-proto.
The above example shows that the argument of a long option, namely
--git-clone-site-params in the example, may be given either separately
or in the same shell argument as the option name, in which case an '='
separator is needed.
When using the 'ssh' protocol, ssh-agent may be used to avoid having to
type the password once for each repository fetched with this protocol.
Also note that gpg-agent(1) can act as an SSH agent.
The main advantage of getopt is that it allows one to define long
options. Help can now be obtained with 'download_and_compile.sh --help',
in addition to the already-existing '-h' option.
[ This is the getopt tool shipped in Debian's util-linux package,
which is marked as Essential, therefore should always be present
on a Debian system. ]
Try to improve formatting of the --help message, so that it is better
suited to document options that have a short as well as a long form.
Make the presentation of this help message a bit more standard.
Florent Rougon