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).
-----------------------
* merge contribution of eatdirt <chris@ringeval.com>
add download, conversion and generation of normalmaps
Big thanks Chris!
* update README and some minor updates to the script
- 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).
This class isn't needed anymore now that
$FG_ROOT/Translations/default/sys.xml has a flat structure, like the
other FG XML i18n files that define the default translation. This is
related to
6d6e1809f0/
and more specifically to
587c601345/
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.
Translation.__setitem__() from flightgear/meta/i18n.py isn't used
anywhere here (it is not very useful), so no harm done, but that could
have confused potential readers.
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).
