- 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.
Since James' recent FG work, the Qt private headers are not needed
anymore for the Qt launcher; clarify this in the comments (they are
still needed for FGQCANVAS, but it is disabled by default).
The qml-module-qtquick-dialogs package is needed for the built-in
launcher's Settings dialog since FlightGear commit
37dc418ce1978a55281cdedf6983e0e3ffea0108.
Forum user daweed reported[1] a nasty error[2] when doing 'git clone' or
'git pull' for FGData with the HTTPS protocol. This error disappeared as
soon as he replaced libcurl4-gnutls-dev with libcurl4-openssl-dev on his
system.
-> favor installation of libcurl4-openssl-dev over libcurl4-gnutls-dev
[1] https://forum.flightgear.org/viewtopic.php?f=20&p=329326#p329324
[2] "RPC failed; curl 56 GnuTLS recv error (-110): The TLS connection
was non-properly terminated"
Typical output of:
dpkg-query --showformat='${Status}\n' --show dctrl-tools
is:
install ok installed
(three words, not one). Thanks to wkitty42 for the report.
Declare qtdeclarative5-private-dev and qml-module-qtquick2 as optional
dependencies, because they are needed for the built-in launcher,
starting from FG commit 3a8d3506d651b770e3173841a034e6203528f465
(committed to FG on 2017-09-26). People who can't install these packages
(oldish systems, etc.) should still be able to build and run FlightGear,
but without the built-in launcher.
See discussion around this message:
https://sourceforge.net/p/flightgear/mailman/message/36059892/
