Scripted Compilation on Linux Debian/Ubuntu

download_and_compile.sh is a Bash script that takes care of downloading and compiling FlightGear and related software from their source code repositories with just one command execution for both 32-bit and 64-bit Debian-based systems. Pre-existing versions (if any) of the software installed by download_and_compile.sh are not touched at all since the script downloads, builds and installs everything under the directory in which it is launched. You can choose the particular components to download, build and install.

Unless told not to do so, download_and_compile.sh installs packages with apt-get. For this reason, it is primarily useful on Debian-based distributions. However, if one disables package installation (using -pn or --sudo=echo) and installs the corresponding dependencies oneself, it can be useful on other Unix-like systems as well—one of the FlightGear developers apparently uses it under OpenBSD.

For hints on using rpm-based distributions such as Redhat, Fedora and CentOS, please see CentOS. Please also see Superbuild.

Introduction

download_and_compile.sh is a Bash script written for Debian-derived distributions (Ubuntu, Devuan, Linux Mint, etc.). Its purpose is to automatically install dependencies using the package manager, then build and install FlightGear-related programs.

By default, download_and_compile.sh installs most dependencies with apt-get run under sudo. Other dependencies, either because they aren't available in the standard APT repositories, or because of non-option arguments passed to download_and_compile.sh, are downloaded and compiled on the fly (this can be the case for PLIB, Simgear and OpenSceneGraph, for instance—it all depends on the arguments passed to the script).

download_and_compile.sh works in the directory it is run from: apart from dependencies installed via the package manager, all programs built by download_and_compile.sh are installed under the install subdirectory of the directory from which the script was run. In other words, installation of programs by download_and_compile.sh is clean, very easy to undo and doesn't interfere with other programs on the system.

It is possible to manage several directory trees with download_and_compile.sh; as far as it is concerned, such directory trees are completely independent from each other. For instance, if you run download_and_compile.sh in dir1 and dir2, the programs installed under dir1 won't “see” those installed under dir2, and vice versa.

Apart from its main purpose, download_and_compile.sh can be used to find hopefully up-to-date build-dependency information for FlightGear and related software. You would do so by inspecting the script at the point where it installs packages.

Prerequisites

Before embarking on building your own FlightGear binaries, you need to install a few tools that download_and_compile.sh uses to retrieve and compile source code. These tools are found in the following packages on Debian systems (and presumably on most Debian derivatives too):

• build-essential
• git
• cmake

These packages can be installed by running a command such as:

$ sudo apt-get install build-essential git cmake

Once this is done, the download_and_compile.sh script can be run. Unless told otherwise, it will install additional tools and libraries as it runs, depending on the chosen components (this will be explained in further sections).

Disk space requirements and build time

As of April 2019, building FlightGear requires about 12 GiB of disk space. Note that this includes downloaded source code for SimGear and FlightGear, generated build files and the large FGData repository (about 6 GiB for that one).

With an Intel Core i7 860 CPU (2.80 GHz) purchased in 2009, compiling SimGear and FlightGear 2019.2 with option -j8 takes about 14 minutes. If you don't have a fast machine and build using only one core, it may require several hours.

Download

You can get download_and_compile.sh from FGMeta. It is contained in the FGMeta repository, which is maintained by the FlightGear developers. The script can be downloaded from the link given above, however, for easier updates and in order to have the command download_and_compile.sh --version work as intended, it is recommended to get it as explained below.

In case you build stable versions of FlightGear using either of the -s, --lts and --old-lts options of download_and_compile.sh, remember to update the script before trying to build a new version of FlightGear (see Updating download_and_compile.sh below). Of course, you can update it more often in order to benefit from new features or bug fixes; this is especially useful if you are building next—that is, the development branch of FlightGear.

Getting started with download_and_compile.sh

For the impatient

So, you're in a hurry, want to build FlightGear but don't want to read any explanation? You can try what follows, but be aware that you may need to come back and read part of the the following sections if you encounter a problem. All commands should be run under a normal user account; however, unless you pass option -pn or something similar to disable installation of packages from your distribution, you'll be asked for your sudo password during execution of the download_and_compile.sh command (sudo is used by download_and_compile.sh to run commands like apt-get). So, here is your quick recipe for getting download_and_compile.sh and using it to build FlightGear:

mkdir -p ~/flightgear/dnc-managed
cd ~/flightgear
git clone https://git.code.sf.net/p/flightgear/fgmeta
cd ~/flightgear/dnc-managed
~/flightgear/fgmeta/download_and_compile.sh -s -j$(nproc)
./run_fgfs.sh --launcher

The -s option passed to download_and_compile.sh instructs it to build the latest stable release of FlightGear. Use option --lts instead if you want the latest Long Term Stable release (it may be older but possibly more stable), or --old-lts for the previous LTS release. If you pass none of -s, --lts and --old-lts, download_and_compile.sh will build the next suite, which contains the development version of FlightGear. For more details on these options, see Release selection.

The command run_fgfs.sh --launcher starts the FlightGear built-in launcher. This is often convenient but not compulsory. Another way to start FlightGear could be ./run_fgfs.sh --airport=PHTO --aircraft=c172p. There are plenty of other options, which are listed by ./run_fgfs.sh --help --verbose.

In some cases, download_and_compile.sh stops and waits for your answer before continuing. This is done when there is something important that you should know. When you are used to these prompts and would rather not see them anymore, pass the --non-interactive option to suppress them.

More detailed instructions are given below. The following sections also explain how to update download_and_compile.sh and FlightGear.

Notations

When a command should be run as an unpriviledged user, it will be preceded by a dollar sign:

$ whoami
toto

In contrast, a hash sign (#) means that the command must be run with superuser privileges to achieve the desired effect:

# whoami
root

In order to make instructions easy to understand, two directories (= folders) will be consistently used for the same purpose below:

• ~/flightgear/fgmeta will contain a clone of the FGMeta repository; therefore, download_and_compile.sh will reside in that directory;
• ~/flightgear/dnc-managed will be the directory from which we run download_and_compile.sh. In other words, with this setup, a typical sequence of commands could be:

$ cd ~/flightgear/dnc-managed
$ ~/flightgear/fgmeta/download_and_compile.sh

or

$ cd ~/flightgear/dnc-managed
$ ~/flightgear/fgmeta/download_and_compile.sh SIMGEAR FGFS DATA OSG

These are of course just examples. The aforementioned paths are not hardwired anywhere in the script; you are free to choose the directories you want for these purposes.

Getting download_and_compile.sh the “right way”

There are several ways to obtain download_and_compile.sh. The method described here makes it very easy to update the script and causes the command download_and_compile.sh --version to work as intended.

As explained in Notations, we want to clone the FGMeta repository in ~/flightgear/fgmeta and work with its next branch. Let's go:

$ mkdir -p ~/flightgear
$ cd ~/flightgear
$ git clone -b next https://git.code.sf.net/p/flightgear/fgmeta

You now have a fresh FGMeta clone in ~/flightgear/fgmeta and your brand new download_and_compile.sh script is located in that directory. You can already try it to see the available options:

$ ~/flightgear/fgmeta/download_and_compile.sh --help
download_and_compile.sh [OPTION...] [--] [COMPONENT...]
Download and compile components belonging to the FlightGear ecosystem.

Without any COMPONENT listed, or if ALL is specified, recompile all
components listed in the WHATTOBUILDALL variable. Each COMPONENT may
be one of the following words:

  ALL, CMAKE, OSG, PLIB, OPENRTI, SIMGEAR, FGFS, DATA, FGRUN, FGO, FGX,
  OPENRADAR, ATCPIE, TERRAGEAR, TERRAGEARGUI, ZLIB.

Available options:
  -h, --help    show this help message and exit
      --version print version and license information, then exit

(...)

Updating download_and_compile.sh

Now that you have download_and_compile.sh from the FGMeta repository, it is very easy to update (this assumes you didn't modify anything yourself inside ~/flightgear/fgmeta!):

$ cd ~/flightgear/fgmeta && git pull

If you want to keep updates as easy as we just showed, it is best not to modify download_and_compile.sh yourself. download_and_compile.sh has plenty of options that usually make it unnecessary to modify the script. Just run download_and_compile.sh --help and learn about the available options when you feel the need to change something. Unless you have special needs that can only be accomodated by modifying download_and_compile.sh, you are invited to skip to the next section.

If you really, really want to modify download_and_compile.sh while keeping updates easy, a good technique is to add your changes to your FGMeta clone in the form of one or more Git commits (no need to push them anywhere, commits can remain in your clone). How to do that is beyond the scope of this document, though; read Git tutorials if you want to learn it (there are plenty on the Internet). Once you have committed your changes to your FGMeta clone, make sure the repository is clean (use git status), then update it with:

$ cd ~/flightgear/fgmeta && git pull --rebase

This will apply your commits on top of the latest commit of the branch that is currently checked out, which so far contained the official version of download_and_compile.sh. In case your changes conflict with the update, Git will tell you and you'll have to resolve the conflict manually (look for “Git resolve conflict” on your favorite search engine)... or start again from a pristine FGMeta clone.

Building FlightGear

In what follows, we won't give the full path to download_and_compile.sh when showing commands to be run, but you should prepend it to download_and_compile.sh whenever you see a download_and_compile.sh command. For instance, if you used the same path as in Notations and see the command:

$ download_and_compile.sh --help

what you should actually run is:

$ ~/flightgear/fgmeta/download_and_compile.sh --help

Apart from this harmless command, do not run other download_and_compile.sh commands from an arbitrary directory, in particular don't run them from ~/flightgear/fgmeta. This is because most other download_and_compile.sh commands write to the current directory (download_and_compile.sh --help and download_and_compile.sh --version are safe to run from any directory, though).

Of course, it is always possible to make commands shorter by setting up aliases (see tips at the end of this message), by adding the directory containing download_and_compile.sh to your PATH or by creating a symbolink link pointing to download_and_compile.sh in a directory that is part of your PATH. This is not necessary, though; do it only if you feel the need (when enabled, persistent shell history is often enough to obviate the need to extend the PATH).

Note  The following commands should be run from an empty directory in a partition that has enough free space (see Disk space requirements and build time). As explained in Notations, we are going to choose the directory ~/flightgear/dnc-managed for this purpose, in order to express that the whole directory tree is managed by download_and_compile.sh. This is just an example; feel free to choose another directory if you want. Don't run the commands from a non-dedicated directory, because it will be filled with files and directories created by download_and_compile.sh and the FlightGear, SimGear, etc. build systems. That would be a complete mess! In particular, don't run the commands from the directory containing your FGMeta clone.

Tip  For some commands, download_and_compile.sh may use sudo. In case you want to run some other program instead of sudo, this can be done with the --sudo option of download_and_compile.sh. For instance, in order to see the commands that would be run with sudo without actually running them, you can pass --sudo=echo to download_and_compile.sh. Like all other options, --sudo must be given before all arguments that are component names (such as SIMGEAR, FGFS, DATA, etc.).

The package manager used by download_and_compile.sh by default is apt-get (it won't be used if you pass download_and_compile.sh the -pn option). You can use another one if you wish, as long as it supports the following calls:

pkg-mgr update
pkg-mgr install pkg1 pkg2 ...

This is the case for aptitude as well as apt. If you want download_and_compile.sh to use aptitude, give it the option --package-manager=aptitude before any of the COMPONENT arguments.

All options of download_and_compile.sh can be seen by running the following command:

$ download_and_compile.sh --help

Now the instructions. You have chosen a dedicated directory where all the stuff that is downloaded and built by download_and_compile.sh will be stored. This is ~/flightgear/dnc-managed if you followed the suggestions given in Notations, and should be empty before you run download_and_compile.sh for the first time. However, it is quite correct to start download_and_compile.sh from the same directory for subsequent runs, even when non-empty (otherwise, download_and_compile.sh would automatically reclone the repositories every time you run it; that would be a sheer waste of time and bandwidth). All that remains to do is to run:

$ mkdir -p ~/flightgear/dnc-managed
$ cd ~/flightgear/dnc-managed
$ download_and_compile.sh -s -j$(nproc)

The -j$(nproc) option is not necessary, but is likely to save you a lot of time; with it, all available CPU cores will be used when compiling—see Multicore acceleration.

Note  Because of the -s option, the above download_and_compile.sh command would build the latest stable release of FlightGear. If you want to build the latest Long Term Stable release, use --lts instead. For the previous LTS release, use --old-lts. If you want to build the development version of FlightGear, use none of -s, --lts and --old-lts, but be warned: it may very well be unstable and unsuitable for flying. For more details on these options, see Release selection.

When you don't pass any non-option argument to download_and_compile.sh as done here, it takes care of the base components needed to run FlightGear in good conditions: SIMGEAR, FGFS, DATA and OSG (these are the component names used by download_and_compile.sh, i.e., the final arguments one can optionally give in a download_and_compile.sh command; in normal speech, they correspond to the SimGear, FlightGear and FGData repositories as well as a suitable repository for OpenSceneGraph). Therefore, the above command is presently exactly equivalent to:

$ download_and_compile.sh -s -j$(nproc) SIMGEAR FGFS DATA OSG

In case you want to build another component such as, say, PLIB, you can add it to the command, like this:

$ download_and_compile.sh -s -j$(nproc) SIMGEAR FGFS DATA OSG PLIB

When the command terminates, you should have a script called run_fgfs.sh in the directory from which you ran download_and_compile.sh (i.e., ~/flightgear/dnc-managed in the suggested setup). This will be your script to run FlightGear. For instance, in order to start the built-in launcher, you can run the following commands:

$ cd ~/flightgear/dnc-managed
$ ./run_fgfs.sh --launcher

(You may omit the --launcher option; this would simply start FlightGear without any launcher, at the default airport and with the default aircraft.)
In case you find this tedious to type or have more arguments to pass on a regular basis, you can follow the advice given at the end of this message or use another launcher such as FFGo—but the FlightGear built-in launcher started with run_fgfs.sh --launcher is quite fine, be sure to try it first!

Note  If you ran download_and_compile.sh from ~/flightgear/dnc-managed as proposed above, the full path of the ~/flightgear/dnc-managed/install/flightgear/fgdata directory is your $FG_ROOT. This is a very important path for FlightGear; knowing this may be useful for troubleshooting or doing “advanced things.”

Updating FlightGear

Note  If you built FlightGear with either of -s, --lts and --old-lts, you need to pass the same option to the download_and_compile.sh command given below that will update your FlightGear installation. Otherwise, download_and_compile.sh will automatically build the next suite (bleeding-edge development version), which is probably not what you wish. Moreover, if you do want to switch from one suite to another (for instance from stable to next, or from Long Term Stable to stable), using the --cleanup option of download_and_compile.sh is heartily recommended.

Keeping the above note in mind, go to the directory from which you previously ran download_and_compile.sh (~/flightgear/dnc-managed in the suggested setup). This is the folder which, if you did a complete run of download_and_compile.sh as shown in the previous section, contains the run_fgfs.sh script and a log file named compilation_log.txt that records what download_and_compile.sh did in its last run. If you wish to update, say, SimGear, FlightGear, FGData and OSG, simply execute this:

$ download_and_compile.sh -pn -j$(nproc) SIMGEAR FGFS DATA OSG

The -j$(nproc) option is not necessary, but is likely to save you a lot of time; with it, all available CPU cores will be used when compiling—see Multicore acceleration.

We'll explain the -pn in a minute. SIMGEAR, FGFS, DATA and OSG are called components in download_and_compile.sh terminology. A component generally corresponds to a software repository, or something close. In fact, since SIMGEAR, FGFS, DATA and OSG are often precisely the components people wish to update, they form the default component set, so that the previous command is equivalent (as of Sept. 2024) to:

$ download_and_compile.sh -pn -j$(nproc)

Now about this -pn. It is equivalent to -p n and means “don't install packages from my (Linux) distribution” (y means yes, please install, n means no, don't install). In case you forgot that, simply run:

$ download_and_compile.sh --help

What does it imply to pass -pn? This tells download_and_compile.sh to completely skip the step where it checks for needed packages from your distribution and installs them, by default using apt-get. It thus goes straight to the following steps:

• update each repository corresponding to one of the selected components (SIMGEAR, FGFS, DATA and OSG in our example);
• compile each selected component that requires compilation;
• install each selected component in the appropriate place (under ~/flightgear/dnc-managed according to our Notations).

In case you don't have all required dependencies for the selected components, one of them is likely to fail, of course, since by passing -pn to download_and_compile.sh, you forbid it to install these dependencies for you. So, you can also very well update without passing the -pn option, it will simply take a little longer (the time to check if all dependencies of the selected components are available with APT). In fact, this is what you should do if the previous download_and_compile.sh run failed: first update download_and_compile.sh (see above) then run it without -pn in case new dependencies have been recently added and you don't have them on your system yet—this would be a very likely cause for the failure. In this case, running download_and_compile.sh --cleanup to restart the build from a clean state is probably a good idea (see Cleaning built and installed files for details on this option).

Summary

Routine update:

$ download_and_compile.sh -pn -j$(nproc) COMPONENT...

In case this fails, first update download_and_compile.sh (see above), then run

$ download_and_compile.sh --cleanup
$ download_and_compile.sh -j$(nproc) COMPONENT...

where COMPONENT... stands for the space-separated list of selected components, and defaults to SIMGEAR FGFS DATA OSG if you don't specify any.

Examining the history of download_and_compile.sh

Looking at the latest commits that affected download_and_compile.sh is quite easy with your FGMeta clone:

$ cd ~/flightgear/fgmeta
$ git log -- download_and_compile.sh

(then quit by typing q, assuming your $GIT_PAGER is less)

In order to do the same, but also see the patch for each commit:

$ cd ~/flightgear/fgmeta
$ git log -p -- download_and_compile.sh

For the curious: the SSH way

The method described below is not necessary anymore since FGMeta commit 420034d5b51ff2d32fc0c3716b17a2d862841e0f (May 2020). What it does is teach you how to clone FGData using SSH, then change the Git remote setup in your clone of that repository to retrieve further updates using https—which is convenient, as it does not require you to provide a password. This technique used to be necessary to securely retrieve FGData because of a problem in the SourceForge infrastructure (namely, git clone from SourceForge doesn't work for the big FGData repository using https). Current versions of download_and_compile.sh avoid the problem by proposing the user to automatically clone FGData from its official mirror at GitLab, then change the Git remote setup to fetch further updates using https from SourceForge.

Because the following method will make you connect to SourceForge using the SSH protocol, you'll need an account on that site. If you don't already have one, go to the registration page and create an account. In all this section, we'll assume that your account name at SourceForge is SFusername.

Note  As explained in Notations, we assume that your Unix user name (login) is toto. Don't confuse the sudo password prompt (where you need to enter toto's password) with the password prompt for your SourceForge account! The former appears as [sudo] password for toto: whereas the latter is just: Password:

Tip  For some commands, download_and_compile.sh may use sudo. In case you want to run some other program instead of sudo, this can be done with the --sudo option of download_and_compile.sh. For instance, in order to see the commands that would be run with sudo without actually running them, you can pass --sudo=echo to download_and_compile.sh. Like all other options, --sudo must be given before all arguments that are component names (such as SIMGEAR, FGFS, DATA, etc.).

Note  The commands given below will build the next suite, which contains the bleeding-edge development version of FlightGear. This is likely to be unstable, possibly unsuitable for flying. If you'd rather build the latest stable release or the latest Long Term Stable release, add option -s or --lts to all download_and_compile.sh commands given below (or --old-lts for the previous LTS release). You may add the chosen option right after the download_and_compile.sh command name (in any case, the option should come before non-option arguments such as SIMGEAR, FGFS, DATA, etc.). See Release selection for more explanations on options -s, --lts and --old-lts.

Now the instructions. You have chosen a dedicated directory where all the stuff that is downloaded and built by download_and_compile.sh will be stored. This is ~/flightgear/dnc-managed in our example, and should be empty before you run download_and_compile.sh for the first time. However, it is quite correct to start download_and_compile.sh from the same directory for subsequent runs, even when non-empty (otherwise, download_and_compile.sh would automatically reclone the repositories every time you run it; that would be a sheer waste of time and bandwidth).

Ready? Let's go!

$ mkdir -p ~/flightgear/dnc-managed
$ cd ~/flightgear/dnc-managed
$ download_and_compile.sh --git-clone-site-params SourceForge=ssh:SFusername DATA
**********************************************************************
*                                                                    *
* Warning: a typical SimGear + FlightGear + FGData build requires    *
* about 12 GiB of disk space. The compilation part may last from a   *
* few minutes to hours, depending on your computer.                  *
*                                                                    *
* Hint: use the -j option if your CPU has several cores, as in:      *
*                                                                    *
*         download_and_compile.sh -j$(nproc)                         *
*                                                                    *
**********************************************************************
Running 'apt-get update'...
[sudo] password for toto:

(...)

Considering a package alternative: libcurl4-openssl-dev libcurl4-gnutls-dev
Package alternative matched for libcurl4-openssl-dev
Running 'apt-get install build-essential git libcurl4-openssl-dev cmake'...
[sudo] password for toto:

(...)

****************************************
**************** DATA ******************
****************************************
Fetching DATA with 'git clone ssh://SFusername@git.code.sf.net/p/flightgear/fgdata'
Cloning into '.'...
The authenticity of host 'git.code.sf.net (216.105.38.16)' can't be established.
ECDSA key fingerprint is SHA256:FeVkoYYBjuQzb5QVAgm3BkmeN5TTgL2qfmqz9tCPRL4.
Are you sure you want to continue connecting (yes/no)?
Warning: Permanently added 'git.code.sf.net,216.105.38.16' (ECDSA) to the list of known hosts.
Connection closed by 216.105.38.16 port 22
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

The above messages are perfectly normal but deserve a little explanation. Here, ssh asked us to confirm that the fingerprint sent by the remote host is that of the real git.code.sf.net, as opposed to that of some malicious server pretending to be git.code.sf.net. This confirmation only has to be done once, after which it is remembered thanks to ~/.ssh/known_hosts. You should visit the page that gives the host key fingerprint of every publically-accessible SSH server at SourceForge and carefully check that the fingerprint appearing on your terminal is listed on that page for git.code.sf.net, or some matching pattern such as *.code.sf.net.

If the fingerprint that is printed on your terminal is not listed on that page, answer no to the question Are you sure you want to continue connecting (yes/no)? and copy/paste to flightgear-devel (see Mailing lists) the above message from ssh that contains the fingerprint sent to you by the remote host which pretends to be git.code.sf.net. If this happened, you should stop here and wait for answers from readers of flightgear-devel.

From now on, we'll assume that the fingerprint you received was correct, and therefore that you have answered yes to the Are you sure you want to continue connecting (yes/no)? question.

In this example, it took us several minutes to verify the fingerprint of the git.code.sf.net server and confirm it to ssh. Because of this delay, git.code.sf.net hung up on us and closed the connection. This is absolutely not a problem: we can just rerun the download_and_compile.sh command with the same arguments as the first time. Since we answered yes to the Are you sure you want to continue connecting (yes/no)? prompt, the fingerprint of git.code.sf.net's key has been stored in ~/.ssh/known_hosts, therefore we won't get this prompt anymore. But if some server claiming to be git.code.sf.net presents a host key that has a different fingerprint in the future, ssh will print a big fat warning that the server may belong to an attacker trying to impersonate git.code.sf.net. Therefore, this SSH host key verification is very useful to protect us from future attacks (which hopefully won't happen at all).

As said, we just rerun the download_and_compile.sh command with the same arguments:

$ download_and_compile.sh --git-clone-site-params SourceForge=ssh:SFusername DATA
**********************************************************************
*                                                                    *
* Warning: a typical SimGear + FlightGear + FGData build requires    *
* about 12 GiB of disk space. The compilation part may last from a   *
* few minutes to hours, depending on your computer.                  *
*                                                                    *
* Hint: use the -j option if your CPU has several cores, as in:      *
*                                                                    *
*         download_and_compile.sh -j$(nproc)                         *
*                                                                    *
**********************************************************************
Running 'apt-get update'...
[sudo] password for toto:

(...)

Considering a package alternative: libcurl4-openssl-dev libcurl4-gnutls-dev
Package alternative matched for libcurl4-openssl-dev
Running 'apt-get install build-essential git libcurl4-openssl-dev cmake'...
[sudo] password for toto:

(...)

****************************************
**************** DATA ******************
****************************************
Fetching DATA with 'git clone ssh://SFusername@git.code.sf.net/p/flightgear/fgdata'
Cloning into '.'...
Password:

As explained above, the preceding prompt is for your SourceForge password (which you could guess from the git clone ssh://SFusername@git.code.sf.net/p/flightgear/fgdata command).

remote: Enumerating objects: 67011, done.
remote: Counting objects: 100% (67011/67011), done.
remote: Compressing objects: 100% (31342/31342), done.
remote: Total 67011 (delta 38776), reused 59640 (delta 33570)
Receiving objects: 100% (67011/67011), 2.60 GiB | 313.00 KiB/s, done.
Resolving deltas: 100% (38776/38776), done.
Checking out files: 100% (12959/12959), done.
Password:

(It will take a fair amount of time to get there, because this is the complete download of FGData.)
This is again a prompt for your SourceForge password, because download_and_compile.sh wants to run git pull --rebase in the repository (admittedly, it's a bit dumb after a clone operation—please forgive us). In case you were not monitoring the clone operation, you probably saw the password prompt way after git.code.sf.net got bored waiting for you and closed our second connection:

Connection closed by 216.105.38.16 port 22
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

(if not, there should be no error message and you should have a clean FGData clone)
No worries. Just as before, simply rerun the command with the same arguments:

$ download_and_compile.sh --git-clone-site-params SourceForge=ssh:SFusername DATA
**********************************************************************
*                                                                    *
* Warning: a typical SimGear + FlightGear + FGData build requires    *
* about 12 GiB of disk space. The compilation part may last from a   *
* few minutes to hours, depending on your computer.                  *
*                                                                    *
* Hint: use the -j option if your CPU has several cores, as in:      *
*                                                                    *
*         download_and_compile.sh -j$(nproc)                         *
*                                                                    *
**********************************************************************
Running 'apt-get update'...
[sudo] password for toto:

(...)

Considering a package alternative: libcurl4-openssl-dev libcurl4-gnutls-dev
Package alternative matched for libcurl4-openssl-dev
Running 'apt-get install build-essential git libcurl4-openssl-dev cmake'...
[sudo] password for toto:

(...)

****************************************
**************** DATA ******************
****************************************
DATA: the repository already exists
Password:
Already up to date.
Current branch next is up to date.
Already on 'next'
Your branch is up to date with 'origin/next'.
All optional package alternatives have found a matching package.

download_and_compile.sh has finished to work.

There we are! You now have a clean, up-to-date FGData clone in ~/flightgear/dnc-managed/install/flightgear/fgdata (remember: ~/flightgear/dnc-managed is the directory from which you ran download_and_compile.sh). Note this place: the full path of the ~/flightgear/dnc-managed/install/flightgear/fgdata directory is your $FG_ROOT.

Now, change the protocol to use for future updates of your FGData clone:

(cd install/flightgear/fgdata && \
git remote set-url origin https://git.code.sf.net/p/flightgear/fgdata)

(you can check at any time the protocol(s) in use with the command git remote -v run inside a Git repository—in this case, inside the folder install/flightgear/fgdata). As a consequence of this change, all future updates of your FGData clone will use the https protocol, therefore you won't be prompted anymore for your SourceForge password.

All that remains to do is to run, from the same directory as before (~/flightgear/dnc-managed in our example):

$ download_and_compile.sh -j$(nproc)

The -j$(nproc) option is not necessary, but is likely to save you a lot of time; with it, all available CPU cores will be used when compiling—see Multicore acceleration.

Assuming the compilation was successful, you can now start the FlightGear built-in launcher using for instance:

$ ./run_fgfs.sh --launcher

See Building FlightGear for more details.

List of available components

The download_and_compile.sh script is able to download, compile (when applicable) and install the following components:

• ATCPIE (for the ATC-pie air traffic control simulation program)
• CMAKE (for the CMake build tool—this can be useful in case CMake is too old in your distribution)
• DATA (for FGData, the main set of data files used by FlightGear)
• FGFS (for FlightGear itself)
• FFGO (for the FFGo FlightGear launcher)
• FGRUN (for the FGRun FlightGear launcher)
• FGX (for the FGx FlightGear launcher)
• OPENRADAR (for the OpenRadar air traffic control simulation program)
• OPENRTI (for OpenRTI)
• OSG (for the OpenSceneGraph library)
• PLIB (for the PLIB library)
• SIMGEAR (for the SimGear library—foundation for FlightGear and TerraGear)
• TERRAGEAR (for the TerraGear terrain building toolchain)
• TERRAGEARGUI (for TerraGear GUI, a graphical interface for TerraGear)
• ZLIB (for the zlib compression library)

Each of the items listed above is a component in download_and_compile.sh terminology. Components are written in uppercase by convention.

Note  The preceding list might not be up-to-date. The up-to-date list of components supported by download_and_compile.sh can always be obtained by running download_and_compile.sh --help.

What is the point of knowing this? Because you may pass component names to download_and_compile.sh in order to tell it what you want to download, build and install. By default, only the components SIMGEAR, FGFS, DATA and OSG are taken care of, which means that the command:

$ download_and_compile.sh

is equivalent to:

$ download_and_compile.sh SIMGEAR FGFS DATA OSG

In case you'd like to do the same build with just PLIB added, you could use:

$ download_and_compile.sh SIMGEAR FGFS DATA OSG PLIB

You get the idea. When several components are passed on the same command line, download_and_compile.sh chooses a reasonable order for processing, so don't worry about that.

When building next, you may encounter problems

Keeping in mind that this script compiles sometimes bleeding edge software, it can happen that what was successfully compiling last week, does not compile anymore today. Building the latest stable version (option -s) or the latest Long Term Stable release (option --lts) should always work, unless there is a problem with the script (well, in some cases, there may be packages of your distribution that are too recent for --lts; for instance, in July 2020, --lts didn't build with OpenSceneGraph 3.6, but simply passing the OSG component on the download_and_compile.sh command solved the problem, because at that time, option --lts selected OpenSceneGraph 3.4).

That said, you may want to build the development version (called next): this is the one developers use all the time, so kindly asking on the flightgear-devel mailing list in case a problem popped up should allow you to find good advice and get the problem quickly fixed, if it's a new one.

Warning  As of July 2020, heavy development will be done on next, the development branch of FlightGear. It is expected to be rather unstable for several months. Unless you are really interested in FlightGear development or in providing feedback to the developers, you're probably better off building either the latest stable version (option -s) or the latest Long Term Stable release (option --lts). In case you want something even older, the previous LTS release can be selected with option --old-lts.

Task-specific instructions

Note  In this section, we assume you've read and followed the advice given in Getting started with download_and_compile.sh.

Selecting the components to build

By default, download_and_compile.sh downloads or updates, then compiles, SimGear, FlightGear, FGData and OSG (more precisely, FGData is downloaded but not compiled—that wouldn't make sense). This is what happens when running:

$ download_and_compile.sh

The preceding command is therefore equivalent to:

$ download_and_compile.sh SIMGEAR FGFS DATA OSG

To make download_and_compile.sh take care of other programs or libraries, use non-option arguments naming the components you want, for instance:

$ download_and_compile.sh SIMGEAR FGFS DATA OSG CMAKE

SIMGEAR, FGFS, DATA, OSG and CMAKE are the component names respectively corresponding to SimGear, FlightGear, FGData, OpenSceneGraph and CMake in download_and_compile.sh's terminology.

A list of available components is provided on this page, but the fully up-to-date list can always be obtained by running download_and_compile.sh --help.

Choosing between stable and development versions

By default, download_and_compile.sh fetches code and data from development branches of the source repositories (which sometimes causes compilation or runtime errors). However, it is possible to tell the script to download the latest “stable” version of each component, for some suitable definition of “stable”. This is by means of the -s, --lts and --old-lts options:

$ download_and_compile.sh -s COMPONENT1 COMPONENT2...

or

$ download_and_compile.sh --lts COMPONENT1 COMPONENT2...

or

$ download_and_compile.sh --old-lts COMPONENT1 COMPONENT2...

How does it work?

• For SimGear, FlightGear and FGData, -s uses the most recent stable release branch of the corresponding Git repository, --lts uses the most recent Long Term Stable release (LTS) and --old-lts uses the previous LTS release.
• For other components, a known-stable version is selected by download_and_compile.sh, which may be influenced by the use of -s, --lts or --old-lts.

So, as far as the SIMGEAR, FGFS and DATA components are concerned, you can:

• build the latest stable release (-s);
• build the latest Long Term Stable release (--lts);
• build the previous Long Term Stable release (--old-lts);
• build the current development version (bleeding edge), which lives in the next branch of the FlightGear repository.

The use of -s, --lts or --old-lts also influences the version of other components you may have selected (this can be overridden using --component-branch for advanced users—see Component-specific settings).

Note  In a given folder where download_and_compile.sh is run, you should normally either always use the -s option, or always use --lts, or always use --old-lts, or always none of these (in other words, stick to the same suite: latest stable, latest LTS, previous LTS or next, consistently accross all components).

Actually, it is possible to switch between suites but you have to use the --cleanup option when doing the switch (see Cleaning built and installed files for information on this option). For instance:

• Build with -s as many times as you want.
• Want to try next? Okay, then build once with --cleanup (no -s option anymore).
• You can then perform as many builds of next as you want; no need to use --cleanup unless something special went wrong.
• If you later decide to switch back to the stable release, build once with -s and --cleanup, then only with -s for further builds.
• etc.

This way, you don't need to download the repositories again when trying the various suites. In particular, you can switch between next, stable, LTS and old LTS without downloading nor having several copies of FGData on your hard drive. (This works because a Git repository may internally contain data for several branches, even if only one is “normally visible” in the filesystem at a given time.)

Building the latest Long Term Stable release of FlightGear

When executing download_and_compile.sh, use the --lts option to build the latest Long Term Stable release:

$ cd ~/flightgear/dnc-managed
$ download_and_compile.sh --lts

(In this example, the implicitly-selected components are SIMGEAR, FGFS and DATA, as explained above.)

Note  If you decide to use the --lts option in a given directory tree, you should use it for all components in that directory tree (SIMGEAR, FGFS, DATA, etc.). Running download_and_compile.sh in a given directory with the --lts option for some components and not for others is not supported.

Building the latest stable release of FlightGear

When executing download_and_compile.sh, use the -s option to build the latest stable release:

$ cd ~/flightgear/dnc-managed
$ download_and_compile.sh -s

Note  If you decide to use the -s option in a given directory tree, you should use it for all components in that directory tree (SIMGEAR, FGFS, DATA, etc.). Running download_and_compile.sh in a given directory with the -s option for some components and not for others is not supported.

Building the current FlightGear development version

When executing download_and_compile.sh without any option, the development version of every selected component is built:

$ cd ~/flightgear/dnc-managed
$ download_and_compile.sh

Note  The development version of FlightGear changes on an almost daily basis. It provides the latest features, but is not guaranteed to always work reliably. If you don't want to take the risk of finding new bugs when updating, you may prefer to use the latest stable release.

Building the previous Long Term Stable release of FlightGear

When executing download_and_compile.sh, use the --old-lts option to build the previous Long Term Stable release (i.e., oldish code):

$ cd ~/flightgear/dnc-managed
$ download_and_compile.sh --old-lts

(In this example, the implicitly-selected components are SIMGEAR, FGFS and DATA, as explained above.)

Note  If you decide to use the --old-lts option in a given directory tree, you should use it for all components in that directory tree (SIMGEAR, FGFS, DATA, etc.). Running download_and_compile.sh in a given directory with the --old-lts option for some components and not for others is not supported.

Overriding the source repository or branch for a component

This section shows how to override the location and/or branch from which a given component will be downloaded.

Warning  The rest of this section is for people who know what they are doing. Don't use the following unless you trust the person who publishes the repository and have good reasons to believe that it has been kept up-to-date.

A short example

Let's start with an example to make it easier to understand to following paragraphs. Suppose we want to build the current stable release of FlightGear, linked against an OpenSceneGraph library whose source code is to be retrieved from branch fgfs-osg-36-2 of the Git repository located at https://gitlab.com/flightgear/openscenegraph.git (this is actually the default in September 2024). Since the default protocol used when download_and_compile.sh clones a repository is HTTPS, this can be done with

download_and_compile.sh --cleanup -s \
--override-repo OSG=GitLab:gitlab.com/flightgear/openscenegraph.git \
--component-branch OSG=fgfs-osg-36-2 SIMGEAR FGFS DATA OSG

The site name

download_and_compile.sh uses case-insensitive short names such as GitHub, SourceForge and gitlab.kitware.com as keys in order to identify the settings describing where and how a given component will be initially fetched (these settings are effective at clone time; later updates simply use the settings recorded in the local repository). These names are referred to as site in the output of download_and_compile.sh --help, in particular in the --git-clone-site-params and --override-repo options we'll present below. These site keys are simply identifier strings; they are not used in the DNS queries.

The protocol

Current download_and_compile.sh (from December 2022) fetches the source code of most components from Git repositories (earlier versions used Subversion for some components); a few non-core components (currently FGo! and OpenRadar) are fetched using wget and are out-of-scope for this section.

The default protocol used by download_and_compile.sh when cloning a Git repository is HTTPS. This can be overridden using the --git-clone-default-proto option. In other words, the default is --git-clone-default-proto=https (the protocol name is case-insensitive). Other possibilities for the protocol are git and ssh.

Warning  The git protocol doesn't protect against man-in-the-middle attacks; use at your own risk! Unfortunately, “clever” people often recommend it on the forum without mentioning its downsides.

Using the ssh protocol as the argument of --git-clone-default-proto has little use, because in general you'll want to specify a particular username when using SSH and this username is likely not to be the same for all components you intend to clone via SSH (right, ~/.ssh/config can be used to automatically provide a site-dependent username). That is why download_and_compile.sh offers the --git-clone-site-params option.

Site-specific settings

Using

--git-clone-site-params SITE=PROTOCOL[:USERNAME]

you can tell download_and_compile.sh that every component fetched from SITE should be cloned with the specified protocol and username (allowed protocols are https, ssh and git).

Note  In case you have several repositories at a given site (say, GitHub) and need to use different SSH usernames for these repositories, you can use different site names: --override-repo COMPONENT_A=GitHubA:ADDRESS_A --git-clone-site-params GitHubA=ssh:userA --override-repo COMPONENT_B=GitHubB:ADDRESS_B --git-clone-site-params GitHubB=ssh:userB Here, the site names are GitHubA and GitHubB; the --override-repo option will be presented below. By default, download_and_compile.sh case-insensitively uses the GitHub (resp. SourceForge) site name to identify the settings used when cloning a repository from github.com (resp. git.code.sf.net). Therefore, the settings for GitHubA and GitHubB in this example would only apply to components c for which --override-repo c=GitHubA:... or --override-repo c=GitHubB:... has been specified.

Component-specific settings

The --override-repo and --component-branch options allow one to override the default settings used by download_and_compile.sh for cloning the repository corresponding to the specified component (they only apply to components whose source code is retrieved with Git). The syntax of these options is

--override-repo COMPONENT=SITE:ADDRESS

and

--component-branch COMPONENT=BRANCH

In this syntax:

• COMPONENT represents the name of a component for download_and_compile.sh (e.g., SIMGEAR—see List of available components);
• ADDRESS is something like git.code.sf.net/p/flightgear/simgear (don't include any protocol:// part in ADDRESS);
• BRANCH should be the name of an existing branch of the Git repository hosted at ADDRESS;
• SITE is a string used as a key in a mapping; download_and_compile.sh uses it to find out how to connect to ADDRESS in order to clone the repository for COMPONENT (see Site-specific settings).

See the above example for a concrete example where these options are used.

Note  The argument of any long option of download_and_compile.sh that takes an argument may be introduced immediately after the option name using an equal sign. However, in the above cases, I find this way a bit confusing because the option value also uses an equal sign as separator. Hence the above use of separate command arguments: one for the option name, one for its argument.

Passing custom arguments to CMake

Sometimes, when building a program, you may want to enable a feature that is not enabled by default, or disable a feature that is enabled by default. With recent versions of download_and_compile.sh (October 2020 or later), this can be done for SimGear and FlightGear using the --sg-cmake-arg and --fg-cmake-arg options (the environment variables SG_CMAKEARGS and FG_CMAKEARGS are still supported, but they don't allow one to pass arguments containing spaces). For instance, in order to link SimGear with the system Expat library, you can do:

$ download_and_compile.sh --sg-cmake-arg='-DSYSTEM_EXPAT=ON' SIMGEAR

Similarly, disabling HID-based input when building FlightGear can be achieved this way:

$ download_and_compile.sh --fg-cmake-arg='-DENABLE_HID_INPUT=OFF' FGFS

Note  Such options are typically defined in CMakeLists.txt files, for example here for SimGear and here for FlightGear.

This can be useful, for instance, to work around bugs in a part of SimGear or FlightGear that you don't need, but causes a build or runtime failure (see here for example). This is often convenient when using the development version of FlightGear, but doesn't mean such bugs shouldn't be reported!

If you have several such options to pass, just use --sg-cmake-arg and/or --fg-cmake-arg several times:

$ download_and_compile.sh --fg-cmake-arg='-DENABLE_SWIFT=ON' \
                          --fg-cmake-arg='-DENABLE_HID_INPUT=OFF' FGFS

It is even possible to pass arguments containing spaces to CMake, as in:

$ download_and_compile.sh \
    --sg-cmake-arg='-DCMAKE_CXX_FLAGS=-Wno-deprecated-declarations -Wall' \
    SIMGEAR

(just a silly example to show a working syntax) or:

$ download_and_compile.sh \
    --fg-cmake-arg="-DCMAKE_CXX_FLAGS=$(pkg-config --cflags gl)" \
    FGFS

Note the use of double-quotes here to enable the $(...) command substitution.

Using the (half-deprecated) environment variables SG_CMAKEARGS and FG_CMAKEARGS, it is also possible to define CMake arguments in a single place that are going to be used for both SimGear and FlightGear. However, this technique doesn't allow one to pass arguments containing spaces to CMake.

$ export SG_CMAKEARGS='-DSYSTEM_EXPAT=ON'
$ export FG_CMAKEARGS='-DENABLE_SWIFT=ON -DENABLE_HID_INPUT=OFF'
$ download_and_compile.sh

Seeing the compilation commands run by Make

As a simple application of the previous section, the following options are often useful. When passed to download_and_compile.sh, these options cause the compilation commands run via Make to be printed on the terminal and recorded in the compilation_log.txt file:

 --sg-cmake-arg='-DCMAKE_VERBOSE_MAKEFILE=1' \
 --fg-cmake-arg='-DCMAKE_VERBOSE_MAKEFILE=1'

(the backslash is unneeded if you put both options on the same line). Passing the value 0 instead of 1 would explicitly request the default, non-verbose behavior.

Launching FlightGear

When using download_and_compile.sh, apart from those installed with the package manager, the FlightGear dependencies (which are typically libraries) are not installed system-wide but under the directory from which download_and_compile.sh was run. This makes it possible to easily use, for instance, different OpenSceneGraph, SimGear and FlightGear versions on a single system—e.g., for testing purposes—but also to have separate build trees (optimized/debug). This is also why you either need to set LD_LIBRARY_PATH to run the built programs, or simply use the scripts created by download_and_compile.sh in the directory where it is run, such as run_fgfs.sh and run_fgfs_debug.sh: these scripts automatically set up the required environment variables according to your build settings before firing the desired program (e.g., fgfs) with the arguments you provided.

Therefore, the simplest way to run a FlightGear program built by download_and_compile.sh is to launch the run_fgfs.sh script that download_and_compile.sh created in the directory from which it was run, for example:

$ cd ~/flightgear/dnc-managed
$ ./run_fgfs.sh --launcher

Note  ./run_fgfs.sh --launcher starts FlightGear with its built-in launcher. If you just do ./run_fgfs.sh, FlightGear will be started without any launcher, at the default airport and with the default aircraft.

In order to start FlightGear without any launcher, at a given airport (say, Paro airport, whose ICAO code is VQPR) and with a chosen aircraft, you can do:

$ cd ~/flightgear/dnc-managed
$ ./run_fgfs.sh --airport=VQPR --aircraft=dhc6

Actually, the directory change is not needed, we only gave it here for readability. Therefore, the following single command does the same:

$ ~/flightgear/dnc-managed/run_fgfs.sh --airport=VQPR --aircraft=dhc6

Avoiding multiple downloads of FGData

Some people use download_and_compile.sh to maintain several directory trees such as the tree starting at ~/flightgear/dnc-managed in Getting started with download_and_compile.sh (this can be useful if you want to have one tree with programs compiled in Release mode and another tree where they are built in Debug mode, for instance). This can easily be done by running download_and_compile.sh in each of the directories. But since FGData is so large, it may be tempting to share a single instance of this repository among several trees. This is not officially supported, but apparently can be made to work with symbolic links.

Let's show how this can be done on an example. Suppose your master copy of FGData is in ~/flightgear/dnc-managed/install/flightgear/fgdata. Then the following appears to work:

$ mkdir -p ~/flightgear/other-dnc-managed-tree/install/flightgear
$ cd ~/flightgear/other-dnc-managed-tree/install/flightgear
$ ln -s ../../../dnc-managed/install/flightgear/fgdata
$ cd ~/flightgear/other-dnc-managed-tree
$ download_and_compile.sh

The last of these commands will use and update the FGData repository present in ~/flightgear/dnc-managed/install/flightgear/fgdata.

Warning  This can only work simply if all trees that share a given FGData repository are from the same release (e.g., current stable or development). Running a “stable“ FlightGear with FGData from the next branch or the other way round, a development version of FlightGear with FGData from a release branch, doesn't work—and FlightGear should tell you when you start it in such a situation. That said, people comfortable with Git can check out the correct FGData branch before building or starting FlightGear, for instance: $ cd /path/to/fgdata && git checkout release/2019.1 or $ cd /path/to/fgdata && git checkout next So, this is possible but somewhat acrobatic. You've been warned.

Note: there is a wiki article about this subject, but it is severely outdated as of April 2019.

Additional programs

Note  In this section, we assume you've read and followed the advice given in Getting started with download_and_compile.sh.

If you wish to get other programs (precisely: download, build and install them), you need to launch download_and_compile.sh with the desired component names as arguments. For instance:

$ cd ~/flightgear/dnc-managed
$ download_and_compile.sh SIMGEAR FGFS DATA OSG

See above for the list of available components.

TerraGear

Run download_and_compile.sh with the TERRAGEAR component in order to build and install the TerraGear terrain building toolchain:

$ cd ~/flightgear/dnc-managed
$ download_and_compile.sh TERRAGEAR

This creates the following scripts in ~/flightgear/dnc-managed:

• run_genapts850.sh
• run_ogr-decode.sh
• run_tg-construct.sh

These scripts themselves run the corresponding TerraGear tools, as expected.

TerraGear GUI

TerraGear GUI is a graphical interface for TerraGear written with the Qt toolkit (still Qt 4 in 2019, but it works). In order to install it, run download_and_compile.sh with the TERRAGEARGUI component:

$ cd ~/flightgear/dnc-managed
$ download_and_compile.sh TERRAGEARGUI

This will create a run_terrageargui.sh script in ~/flightgear/dnc-managed, and also a default configuration file ~/.config/TerraGear/TerraGearGUI.conf, unless you already have one. This default configuration file contains paths to the TerraGear and $FG_ROOT directories, assuming you have installed the TERRAGEAR and DATA components.

To run TerraGear GUI:

$ cd ~/flightgear/dnc-managed
$ ./run_terrageargui.sh

FGCom

Note  FGCom has been integrated into FlightGear long ago, therefore the following is not needed in general.

FGCom is the system used by FlightGear to simulate radio communications between users. It is automatically built and installed when you tell download_and_compile.sh to take care of the FGFS component. You can launch the standalone FGCom program by using the run_fgcom.sh script:

$ cd ~/flightgear/dnc-managed
$ ./run_fgcom.sh

FGRun

Note  As of 2019, FGRun has been superseded by the FlightGear built-in launcher. The built-in launcher is the most actively maintained launcher for FlightGear. Other launchers are FFGo and FGx.

Before FlightGear had its built-in launcher (the one you get with run_fgfs.sh --launcher), many users found comfortable having FlightGear launched by the graphical utility FGRun. This program is built and installed when download_and_compile.sh is run with the FGRUN component. You then have to launch the run_fgrun.sh command, for example:

$ cd ~/flightgear/dnc-managed
$ ./run_fgrun.sh

FGRun will save its settings in ~/.fltk/flightgear.org/fgrun.prefs. You may want to save copies of the preferences customized for stable and next.

FGo!

Note  As of 2019, FGo! is not maintained anymore. You may want to try the built-in launcher (started with run_fgfs.sh --launcher) or FFGo.

FGo! is a graphical utility written in python. It is downloaded and installed when download_and_compile.sh is run with the FGO component. You then have to launch the run_fgo.sh command, for example:

$ cd ~/flightgear/dnc-managed
$ ./run_fgo.sh

Remember that the first time you run it, you have to go to open the Preferences dialog and set the paths to the fgfs executable and to FGData.

Troubleshooting

Compilation errors

Here we are, no fear, if you wish to use programs from the cvs/svn/git repositories, you might face compilation errors that will prevent you to have a working copy of one or more of the programs provided by this script. What can be the causes that prevent us from successfully compiling? As far as I know those:

1. Software developers introduce a new functionality with a new piece of code that prevents the compilation under your architecture, this can happen working with cvs/svn/git sources.
2. The program refuses to compile because of a divergence in the libraries on which it depends. For example FlightGear might not compile because OSG has been modified, while OSG itself compiles fine, FG won't.
3. One or more repositories are down and you can't get the library you need. (Both from cvs/svn/git or apt-get)

There is a simple solution to the above errors: wait and relaunch the script after some time (hours or days), if software developers repair or synchronize their code with the newly updated libraries (which generally happens eventually), your FlightGear will compile fine as if the previous error never took place.

Sometimes it happens that the script fails to compile only FGRun, FGCom or atlas, if you then see the run_fgfs.sh file it means that FlightGear installation was successful and you can safely run it.

OpenRTI undefined reference errors

Sometimes, due to the way download_and_compile.sh builds projects, linking errors might occur. This is the case with the error “libRTI-NG.so: undefined reference to xxx”. You might want to patch the download_and_compile.sh script to clean OpenRTI with rm -f CMakeCache.txt && rm -rf CMakeFiles/, or just restart the build in a clean environment. Assuming you are in the base directory from which you ran download_and_compile.sh, you can run download_and_compile.sh --cleanup (see Cleaning built and installed files). Alternatively, the following command could be used:

$ rm -rf build/* install/simgear/ install/openrti/ install/flightgear/share/ install/flightgear/bin/

See this thread for more details. Note that download_and_compile.sh didn't have the --cleanup option at that time!

Options

Release selection

• Build the latest stable release: -s
• Build the latest Long Term Stable release: --lts
• Build the previous Long Term Stable release: --old-lts

Long Term Stable (--lts) is supposed to yield a more stable setup than what you would obtain with option -s, however it will generally be older. Both of these options are suitable for users.

If you pass none of -s, --lts and --old-lts in a download_and_compile.sh invocation, you'll build the the next suite, which contains the development version of FlightGear. The corresponding FlightGear code will be very recent but may well be unstable—this is particularly the case starting from July 2020. This is therefore mostly intended for developers.

Skipping most prompts

For some important things, download_and_compile.sh asks for confirmation in order to be sure that you are well informed about what will be done. When you have a good understanding of these informations, you may want to use the --non-interactive option in order to suppress these prompts (technically, this causes the default answer to be automatically used).

Cleaning built and installed files

Option --cleanup causes download_and_compile.sh to remove everything that was built and installed in the directory it is run from. The Git repositories will not be removed, so this is good if you want to restart a compilation from a clean state.

If you use --cleanup without specifying any component, only this removal will be done (nothing will be compiled nor installed). Otherwise, the usual rules concerning components apply.

Multicore acceleration

Passing option -j x to download_and_compile.sh (where x is the number of your CPU cores you wish to assign to the job) will considerably speed up the compilation steps. Passing -j$(nproc) is a convenient way to automatically use all available cores.

Advanced options

• Build a release version: -b Release
• Build a version that should run as fast as a release build, yet has debug information that can be used to post backtraces: -b RelWithDebInfo (this is the default)
• Build a full debug version for very complete bug reporting: -b Debug
• Skip download of distro packages (i.e., by default: apt-get install ...): -p n
• Skip retrieving of component downloads and updates (which typically use Git or wget): -d n
• Skip the configure step (like running CMake or autoconf's ./configure): -r n
• Skip compilation of programs: -c n
• Build with compositor: --compositor
• Force the use of a particular branch for a given component: --component-branch COMPONENT=BRANCH (e.g., --component-branch OSG=OpenSceneGraph-3.6, --component-branch FGFS=next, etc.—but remember that components FGFS, SIMGEAR and DATA must always be in sync). See Component-specific settings for details.
• Override the repository from which a given component is initially fetched: --override-repo COMPONENT=SITE:ADDRESS (see Component-specific settings).
• Generate build.ninja files and build using Ninja: -G Ninja
• Run CMake in verbose mode: --verbose (this shows compilation commands)

For example, if you are a developer and wish to quickly recompile and reinstall only your own modifications for FlightGear, you can do this:

$ download_and_compile.sh -j$(nproc) -p n -d n -r n FGFS

Note that this is the same as:

$ download_and_compile.sh -j$(nproc) -pn -dn -rn FGFS

This command will only rebuild modified files and reinstall FlightGear. Note that depending on the kind of changes you made, reconfiguring and thus dropping the -rn option may be necessary, though (this is the case in particular if you added or removed C++ files).

ccache

ccache is a compiler cache that can help speed up subsequent re-compilations. Even if ccache is installed and in the $PATH, the download_and_compile.sh won't use it by default. To use it, install it, such as via apt install ccache. Then enable it when building with download_and_compile.sh by one of the below methods.

Export in environment:

export CMAKE_CXX_COMPILER_LAUNCHER=ccache

Or when running download_and_compile.sh add this option (does not work on 2024.1, but works with -next branch):

--cmake-arg=ALL="CMAKE_CXX_COMPILER_LAUNCHER=ccache"

Optimus technology

If your computer has a GPU with Optimus technology, you need a dedicated script in order to make FlightGear run with the powerful GPU.

After having installed required tools (Bumblebee) you just need to run this command line in your FlightGear installation directory (where you executed download_and_compile.sh):

$ sed  's|\./fgfs|optirun ./fgfs|' run_fgfs.sh > run_fgfs_optirun.sh && chmod +x run_fgfs_optirun.sh

Now you can run FlightGear with ./run_fgfs_optirun.sh.

The same can be done for the FGRun launcher:

$ sed  's|\./fgrun|optirun ./fgrun|' run_fgrun.sh > run_fgrun_optirun.sh && chmod +x run_fgrun_optirun.sh

See also

• Other FlightGear build scripts present in FGMeta
• fg-from-scratch
• Another script for building FlightGear and all its dependencies in an automated fashion. The page seems a bit oldish, though (as of 2019).