FlightGear wiki - User contributions [en]

Scripted Compilation on Linux Debian/Ubuntu

2025-01-03T01:34:41Z

Jebba: /* ccache */ Think it needs that -D...

<tt>download_and_compile.sh</tt> 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<ref name="just-one-command">Due to technical problems on the [https://sourceforge.net/ SourceForge] side, this is currently only true once you have an [[FGData]] clone. See [[User:Rominet|here]] for details.</ref> for both 32-bit and 64-bit [https://www.debian.org/ Debian]-based systems. Pre-existing versions (if any) of the software installed by <tt>download_and_compile.sh</tt> 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, <tt>download_and_compile.sh</tt> installs packages with <tt>apt-get</tt>. For this reason, it is primarily useful on Debian-based distributions. However, if one disables package installation (using <code>-pn</code> or <code>--sudo=echo</code>) 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 [https://www.openbsd.org/ OpenBSD].

For hints on using <tt>rpm</tt>-based distributions such as Redhat, Fedora and CentOS, please see [[CentOS]]. Please also see [[Superbuild]].

== Introduction ==

<tt>download_and_compile.sh</tt> is a [https://www.gnu.org/software/bash/ Bash] script written for [https://www.debian.org/ Debian]-derived distributions ([https://www.ubuntu.com/ Ubuntu], [https://devuan.org/ Devuan], [https://www.linuxmint.com/ Linux Mint], etc.). Its purpose is to automatically install dependencies using the package manager, then build and install FlightGear-related programs.

By default, <tt>download_and_compile.sh</tt> installs most dependencies with <tt>apt-get</tt> run under <tt>sudo</tt>.<ref name="disabling-installation-of-dependencies-via-package-manager">If you think you already have the dependencies, this installation can be disabled either by using option <code>-pn</code> or by passing option <code>--sudo=echo</code> (the latter results in printing the <tt>apt-get</tt> command line without running it).</ref> Other dependencies, either because they aren't available in the standard APT repositories, or because of non-option arguments passed to <tt>download_and_compile.sh</tt>, 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).

<tt>download_and_compile.sh</tt> works in the directory it is run from: apart from dependencies installed via the package manager, all programs built by <tt>download_and_compile.sh</tt> are installed under the <tt>install</tt> subdirectory of the directory from which the script was run. In other words, installation of programs by <tt>download_and_compile.sh</tt> 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 <tt>download_and_compile.sh</tt>; as far as it is concerned, such directory trees are completely independent from each other. For instance, if you run <tt>download_and_compile.sh</tt> in <tt>dir1</tt> and <tt>dir2</tt>, the programs installed under <tt>dir1</tt> won't “see” those installed under <tt>dir2</tt>, and vice versa.

Apart from its main purpose, <tt>download_and_compile.sh</tt> can be used to find hopefully up-to-date build-dependency information for FlightGear and related software. You would do so by inspecting [https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/download_and_compile.sh the script] at the point where it installs packages.<ref name="note-inspecting-download-and-compile-sh-to-gather-build-dependency-information">Look for strings such as <tt>zlib1g-dev</tt>, <tt>libglew-dev</tt> or <tt>qt5-default</tt>.</ref>

== Prerequisites ==

Before embarking on building your own FlightGear binaries, you need to install a few tools that <tt>download_and_compile.sh</tt> uses to retrieve and compile source code. These tools are found in the following packages on [https://www.debian.org/ 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 <tt>download_and_compile.sh</tt> 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 [https://en.wikipedia.org/wiki/Gibibyte 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 <code>-j8</code> 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 <tt>download_and_compile.sh</tt> {{fgmeta source
| path = download_and_compile.sh
| text = 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 <code>download_and_compile.sh --version</code> work as intended, it is recommended to get it as explained [[#getting-download-and-compile-sh-using-an-fgmeta-clone|below]].

In case you build stable versions of FlightGear using either of the <code>-s</code>, <code>--lts</code> and <code>--old-lts</code> options of <tt>download_and_compile.sh</tt>, remember to update the script before trying to build a new version of FlightGear (see [[#updating-download-and-compile-sh-using-an-fgmeta-clone|Updating <tt>download_and_compile.sh</tt>]] 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 <tt>download_and_compile.sh</tt> ==

=== 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 <code>-pn</code> or something similar to disable installation of packages from your distribution, you'll be asked for your <tt>sudo</tt> password during execution of the <tt>download_and_compile.sh</tt> command (<tt>sudo</tt> is used by <tt>download_and_compile.sh</tt> to run commands like <tt>apt-get</tt>). So, here is your quick recipe for getting <tt>download_and_compile.sh</tt> and using it to build FlightGear:
mkdir -p ~/flightgear/dnc-managed
cd ~/flightgear
<nowiki>git clone https://git.code.sf.net/p/flightgear/fgmeta</nowiki>
cd ~/flightgear/dnc-managed
~/flightgear/fgmeta/download_and_compile.sh -s -j$(nproc)
./run_fgfs.sh --launcher

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

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

In some cases, <tt>download_and_compile.sh</tt> 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 <code>--non-interactive</code> option to suppress them.

More detailed instructions are given below. The following sections also explain how to update <tt>download_and_compile.sh</tt> 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:
* <tt>~/flightgear/fgmeta</tt> will contain a clone of the [[FGMeta]] repository; therefore, <tt>download_and_compile.sh</tt> will reside in that directory;
* <tt>~/flightgear/dnc-managed</tt> will be the directory from which we run <tt>download_and_compile.sh</tt>. 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 <tt>download_and_compile.sh</tt> the “right way” ===

There are several ways to obtain [https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/download_and_compile.sh download_and_compile.sh]. The method described here makes it very easy to update the script and causes the command <code>download_and_compile.sh --version</code> to work as intended.

As explained in [[#getting-started-with-download-and-compile-sh-notations|Notations]], we want to clone the [[FGMeta]] repository in <tt>~/flightgear/fgmeta</tt> and work with its ''next'' branch. Let's go:
$ mkdir -p ~/flightgear
$ cd ~/flightgear
<nowiki>$ git clone -b next https://git.code.sf.net/p/flightgear/fgmeta</nowiki>
You now have a fresh FGMeta clone in <tt>~/flightgear/fgmeta</tt> and your brand new <tt>download_and_compile.sh</tt> script is located in that directory. You can already try it to see the available options:
<pre>$ ~/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

(...)</pre>

=== Updating <tt>download_and_compile.sh</tt> ===

Now that you have <tt>download_and_compile.sh</tt> from the [[FGMeta]] repository, it is very easy to update (this assumes you didn't modify anything yourself inside <tt>~/flightgear/fgmeta</tt>!):
$ cd ~/flightgear/fgmeta && git pull

If you want to keep updates as easy as we just showed, it is best not to modify <tt>download_and_compile.sh</tt> yourself. <tt>download_and_compile.sh</tt> has plenty of options that usually make it unnecessary to modify the script. Just run <code>download_and_compile.sh --help</code> 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 <tt>download_and_compile.sh</tt>, you are invited to skip to the next section.

If you really, ''really'' want to modify <tt>download_and_compile.sh</tt> 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 <code>git status</code>), 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 <tt>download_and_compile.sh</tt>. 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 <tt>download_and_compile.sh</tt> when showing commands to be run, but you should prepend it to <tt>download_and_compile.sh</tt> whenever you see a <tt>download_and_compile.sh</tt> command. For instance, if you used the same path as in [[#getting-started-with-download-and-compile-sh-notations|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 <tt>download_and_compile.sh</tt> commands from an arbitrary directory, in particular ''don't'' run them from <tt>~/flightgear/fgmeta</tt>. This is because '''most other <tt>download_and_compile.sh</tt> commands write to the current directory''' (<code>download_and_compile.sh --help</code> and <code>download_and_compile.sh --version</code> 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 [https://sourceforge.net/p/flightgear/mailman/message/36634426/ this message]), by adding the directory containing <tt>download_and_compile.sh</tt> to your <tt>PATH</tt> or by creating a symbolink link pointing to <tt>download_and_compile.sh</tt> in a directory that is part of your <tt>PATH</tt>. 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 <tt>PATH</tt>).

{{Note|The following commands should be run from an empty directory<ref name="dedicated-directory-won-t-stay-empty-forever">Well, empty before the first time; later, <tt>download_and_compile.sh</tt> is going to populate it with plenty of FlightGear files and subdirectories, of course.</ref> in a partition that has enough free space (see [[#disk-space-requirements-and-build-time | Disk space requirements and build time]]). As explained in [[#getting-started-with-download-and-compile-sh-notations|Notations]], we are going to choose the directory <tt>~/flightgear/dnc-managed</tt> for this purpose, in order to express that the whole directory tree is managed by <tt>download_and_compile.sh</tt>. 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 <tt>download_and_compile.sh</tt> 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, <tt>download_and_compile.sh</tt> may use <tt>sudo</tt>. In case you want to run some other program instead of <tt>sudo</tt>, this can be done with the <code>--sudo</code> option of <tt>download_and_compile.sh</tt>. For instance, in order to see the commands that would be run with sudo without actually running them, you can pass <code><nowiki>--sudo=echo</nowiki></code> to <tt>download_and_compile.sh</tt>. Like all other options, <code>--sudo</code> must be given ''before'' all arguments that are component names (such as <tt>SIMGEAR</tt>, <tt>FGFS</tt>, <tt>DATA</tt>, etc.).}}

The package manager used by <tt>download_and_compile.sh</tt> by default is <tt>apt-get</tt> (it won't be used if you pass <tt>download_and_compile.sh</tt> the <code>-pn</code> 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 <tt>aptitude</tt> as well as <tt>apt</tt>. If you want <tt>download_and_compile.sh</tt> to use <tt>aptitude</tt>, give it the option <code><nowiki>--package-manager=aptitude</nowiki></code> before any of the ''COMPONENT'' arguments.

All options of <tt>download_and_compile.sh</tt> 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 <tt>download_and_compile.sh</tt> will be stored. This is <tt>~/flightgear/dnc-managed</tt> if you followed the suggestions given in [[#getting-started-with-download-and-compile-sh-notations|Notations]], and should be empty before you run <tt>download_and_compile.sh</tt> for the first time. However, it is quite correct to start <tt>download_and_compile.sh</tt> from the same directory for subsequent runs, even when non-empty (otherwise, <tt>download_and_compile.sh</tt> 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 <code>-j$(nproc)</code> 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| Multicore acceleration]].

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

When you don't pass any non-option argument to <tt>download_and_compile.sh</tt> as done here, it takes care of the base components needed to run FlightGear in good conditions: <tt>SIMGEAR</tt>, <tt>FGFS</tt>, <tt>DATA</tt> and <tt>OSG</tt> (these are the component names used by <tt>download_and_compile.sh</tt>, i.e., the final arguments one can optionally give in a <tt>download_and_compile.sh</tt> command; in normal speech, they correspond to the {{simgear source
| text = SimGear
}}, {{flightgear source
| text = FlightGear
}} and {{fgdata source
| text = 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 <tt>run_fgfs.sh</tt> in the directory from which you ran <tt>download_and_compile.sh</tt> (i.e., <tt>~/flightgear/dnc-managed</tt> in the suggested setup). This will be your script to run FlightGear. For instance, in order to start the [[FlightGear Qt launcher|built-in launcher]], you can run the following commands:<ref name="no-need-to-change-to-dnc-managed-dir-before-starting-generated-scripts">We give these commands because they are easy to read, but the <code>cd</code> command is not needed if you use the correct path, as in <code>~/flightgear/dnc-managed/run_fgfs.sh --launcher</code>.</ref>
$ cd ~/flightgear/dnc-managed
$ ./run_fgfs.sh --launcher
(You may omit the <code>--launcher</code> 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 [https://sourceforge.net/p/flightgear/mailman/message/36634426/ this message] or use another launcher such as [[FFGo]]—but the [[FlightGear Qt launcher|FlightGear built-in launcher]] started with <code>run_fgfs.sh --launcher</code> is quite fine, be sure to try it first!

{{Note|If you ran <tt>download_and_compile.sh</tt> from <tt>~/flightgear/dnc-managed</tt> as proposed above, the full path of the <tt>~/flightgear/dnc-managed/install/flightgear/fgdata</tt> 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 <code>-s</code>, <code>--lts</code> and <code>--old-lts</code>, you need to pass the ''same option'' to the <tt>download_and_compile.sh</tt> command given below that will update your FlightGear installation. Otherwise, <tt>download_and_compile.sh</tt> 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 <code>--cleanup</code> option of <tt>download_and_compile.sh</tt> is heartily recommended.}}

Keeping the above note in mind, go to the directory from which you previously ran <tt>download_and_compile.sh</tt> (<tt>~/flightgear/dnc-managed</tt> in the [[#Notations|suggested setup]]). This is the folder which, if you did a complete run of <tt>download_and_compile.sh</tt> as shown in the previous section, contains the <tt>run_fgfs.sh</tt> script and a log file named <tt>compilation_log.txt</tt> that records what <tt>download_and_compile.sh</tt> did in its last run. If you wish to update, say, {{simgear source
| text = SimGear
}}, {{flightgear source
| text = FlightGear
}}, {{fgdata source
| text = FGData
}} and [[OpenSceneGraph|OSG]], simply execute this:
$ download_and_compile.sh -pn -j$(nproc) SIMGEAR FGFS DATA OSG
The <code>-j$(nproc)</code> 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| Multicore acceleration]].

We'll explain the <code>-pn</code> in a minute. <tt>SIMGEAR</tt>, <tt>FGFS</tt>, <tt>DATA</tt> and <tt>OSG</tt> are called ''components'' in <tt>download_and_compile.sh</tt> terminology. A component generally corresponds to a software repository, or something close. In fact, since <tt>SIMGEAR</tt>, <tt>FGFS</tt>, <tt>DATA</tt> and <tt>OSG</tt> 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 <code>-pn</code>. It is equivalent to <code>-p n</code> and means “don't install packages from my (Linux) distribution” (<code>y</code> means ''yes, please install'', <code>n</code> means ''no, don't install''). In case you forgot that, simply run:
$ download_and_compile.sh --help
What does it imply to pass <code>-pn</code>? This tells <tt>download_and_compile.sh</tt> to completely skip the step where it checks for needed packages from your distribution and installs them, by default using <tt>apt-get</tt>. It thus goes straight to the following steps:
* update each repository corresponding to one of the selected components (<tt>SIMGEAR</tt>, <tt>FGFS</tt>, <tt>DATA</tt> and <tt>OSG</tt> in our example);
* compile each selected component that requires compilation;
* install each selected component in the appropriate place (under <tt>~/flightgear/dnc-managed</tt> according to our [[#getting-started-with-download-and-compile-sh-notations|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 <code>-pn</code> to <tt>download_and_compile.sh</tt>, you forbid it to install these dependencies for you. So, you can also very well update without passing the <code>-pn</code> option, it will simply take a little longer (the time to check if all dependencies of the selected components are available with <tt>APT</tt>). In fact, this is '''what you should do if the previous <tt>download_and_compile.sh</tt> run failed:''' first update <tt>download_and_compile.sh</tt> (see [[#getting-download-and-compile-sh-using-an-fgmeta-clone|above]]) then run it ''without'' <code>-pn</code><ref name="passing-no-pn-option-equals-passing-py">Which is the same as passing <code>-py</code>.</ref> 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 <code>download_and_compile.sh --cleanup</code> to restart the build from a clean state is probably a good idea (see [[#Cleaning built and installed files|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 <tt>download_and_compile.sh</tt> (see [[#getting-download-and-compile-sh-using-an-fgmeta-clone|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 <tt>SIMGEAR FGFS DATA OSG</tt> if you don't specify any.

=== Examining the history of <tt>download_and_compile.sh</tt> ===

Looking at the latest commits that affected <tt>download_and_compile.sh</tt> is quite easy with your FGMeta clone:
$ cd ~/flightgear/fgmeta
$ git log -- download_and_compile.sh
(then quit by typing <tt>q</tt>, assuming your <tt>$GIT_PAGER</tt> is <tt>less</tt>) 

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 [https://sourceforge.net/ SourceForge] infrastructure (namely, <code>git clone</code> from SourceForge doesn't work for the big FGData repository using https). Current versions of <tt>download_and_compile.sh</tt> avoid the problem by proposing the user to automatically clone FGData from its [https://gitlab.com/flightgear/fgdata 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 [https://sourceforge.net/ SourceForge] using the SSH protocol, you'll need an account on that site. If you don't already have one, go to the [https://sourceforge.net/user/registration 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 [[#getting-started-with-download-and-compile-sh-notations|Notations]], we assume that your Unix user name (login) is <tt>toto</tt>. Don't confuse the <tt>sudo</tt> password prompt (where you need to enter <tt>toto</tt>'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, <tt>download_and_compile.sh</tt> may use <tt>sudo</tt>. In case you want to run some other program instead of <tt>sudo</tt>, this can be done with the <code>--sudo</code> option of <tt>download_and_compile.sh</tt>. For instance, in order to see the commands that would be run with sudo without actually running them, you can pass <code><nowiki>--sudo=echo</nowiki></code> to <tt>download_and_compile.sh</tt>. Like all other options, <code>--sudo</code> must be given ''before'' all arguments that are component names (such as <tt>SIMGEAR</tt>, <tt>FGFS</tt>, <tt>DATA</tt>, 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 <code>-s</code> or <code>--lts</code> to all <tt>download_and_compile.sh</tt> commands given below (or <code>--old-lts</code> for the previous LTS release). You may add the chosen option right after the <tt>download_and_compile.sh</tt> command name (in any case, the option should come before non-option arguments such as SIMGEAR, FGFS, DATA, etc.). See [[#Release selection|Release selection]] for more explanations on options <code>-s</code>, <code>--lts</code> and <code>--old-lts</code>.}}

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

Ready? Let's go!
<pre>$ 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.
</pre>

The above messages are perfectly normal but deserve a little explanation. Here, <tt>ssh</tt> asked us to confirm that the fingerprint sent by the remote host is that of the real <tt>git.code.sf.net</tt>, as opposed to that of some malicious server ''pretending'' to be <tt>git.code.sf.net</tt>. This confirmation only has to be done once, after which it is remembered thanks to <tt>~/.ssh/known_hosts</tt>. You should visit the [https://sourceforge.net/p/forge/documentation/SSH%20Key%20Fingerprints/#fingerprint-listing 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 <tt>git.code.sf.net</tt>, or some matching pattern such as <tt>*.code.sf.net</tt>.

If the fingerprint that is printed on your terminal is not listed on that page, answer <tt>no</tt> 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 <tt>ssh</tt> that contains the fingerprint sent to you by the remote host which pretends to be <tt>git.code.sf.net</tt>. 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 <tt>yes</tt> 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 <tt>git.code.sf.net</tt> server and confirm it to <tt>ssh</tt>. Because of this delay, <tt>git.code.sf.net</tt> hung up on us and closed the connection. This is absolutely ''not a problem:'' we can just rerun the <tt>download_and_compile.sh</tt> command with the same arguments as the first time. Since we answered <tt>yes</tt> to the ''Are you sure you want to continue connecting (yes/no)?'' prompt, the fingerprint of <tt>git.code.sf.net</tt>'s key has been stored in <tt>~/.ssh/known_hosts</tt>, therefore we won't get this prompt anymore. But if some server claiming to be <tt>git.code.sf.net</tt> presents a host key that has a different fingerprint in the future, <tt>ssh</tt> will print a big fat warning that the server may belong to an attacker trying to impersonate <tt>git.code.sf.net</tt>. 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 <tt>download_and_compile.sh</tt> command with the same arguments:
<pre>$ 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:</pre>
As explained above, the preceding prompt is for your SourceForge password (which you could guess from the <code><nowiki>git clone ssh://SFusername@git.code.sf.net/p/flightgear/fgdata</nowiki></code> command).
<pre>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:</pre>
(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 <tt>download_and_compile.sh</tt> wants to run <code>git pull --rebase</code> in the repository (admittedly, it's a bit dumb after a <tt>clone</tt> operation—please forgive us). In case you were not monitoring the <tt>clone</tt> operation, you probably saw the password prompt way after <tt>git.code.sf.net</tt> got bored waiting for you and closed our second connection:
<pre>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.</pre>
(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:
<pre>$ 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.
</pre>
There we are! You now have a clean, up-to-date [[FGData]] clone in <tt>~/flightgear/dnc-managed/install/flightgear/fgdata</tt> (remember: <tt>~/flightgear/dnc-managed</tt> is the directory from which you ran <tt>download_and_compile.sh</tt>). Note this place: the full path of the <tt>~/flightgear/dnc-managed/install/flightgear/fgdata</tt> directory is your [[$FG_ROOT]].

Now, change the protocol to use for future updates of your FGData clone:<ref name="changing-the-protocol-for-a-git-remote-manual-method">Another way would be to manually change the relevant line starting with <code>url = <nowiki>ssh://SFusername@</nowiki></code> for the <code>origin</code> remote in the <tt>.git/config</tt> file that lives inside your repository clone (i.e., <tt>~/flightgear/dnc-managed/install/flightgear/fgdata/.git/config</tt> in our example).</ref>
(cd install/flightgear/fgdata && \
git remote set-url origin <nowiki>https://git.code.sf.net/p/flightgear/fgdata</nowiki>)
(you can check at any time the protocol(s) in use with the command <code>git remote -v</code> run inside a Git repository—in this case, inside the folder <tt>install/flightgear/fgdata</tt>). As a consequence of this change, all future updates of your FGData clone will use the <tt>https</tt> 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 (<tt>~/flightgear/dnc-managed</tt> in our example):
$ download_and_compile.sh -j$(nproc)
The <code>-j$(nproc)</code> 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| Multicore acceleration]].

Assuming the compilation was successful, you can now start the [[FlightGear Qt launcher|FlightGear built-in launcher]] using for instance:
$ ./run_fgfs.sh --launcher
See [[#Building FlightGear|Building FlightGear]] for more details.

== List of available components ==

The <tt>download_and_compile.sh</tt> 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 [https://cmake.org/ 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|FGRun]] FlightGear launcher)
* FGX (for the [[FGX|FGx]] FlightGear launcher<ref name="note-on-the-status-of-FGx-support-in-download-and-compile-sh">Support for FGx in <tt>download_and_compile.sh</tt> would probably benefit from a code review.</ref>)
* OPENRADAR (for the [[OpenRadar]] air traffic control simulation program)
* OPENRTI (for [[FlightGear HLA support (High Level Architecture)#OpenRTI | OpenRTI]]<ref name="note-on-the-status-of-OpenRTI-support-in-FG">Note that OpenRTI is just an optional dependency for [[FlightGear high-level architecture support | HLA support]]. For the time being, you should be just fine building without it. Eventually, the idea is for HLA to replace the existing MP system and even increasingly distribute the FlightGear architecture such that more and more components can be more easily run in separate threads or even separate processes, possibly even on different machines. So this is going to be an important feature for professional users, using several computers and screens to create a comprehensive and immersive simulation environment.

At the moment, it is probably safe to say that HLA is only of interest to developers and people willing to play with experimental features.</ref>)
* 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 [http://www.zlib.net/ zlib] compression library)

Each of the items listed above is a ''component'' in <tt>download_and_compile.sh</tt> 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 <tt>download_and_compile.sh</tt> can always be obtained by running <code>download_and_compile.sh --help</code>.}}

What is the point of knowing this? Because you may pass component names to <tt>download_and_compile.sh</tt> in order to tell it what you want to download, build and install. By default, only the components [[SimGear|SIMGEAR]], [[FlightGear|FGFS]], [[FGData|DATA]] and [[OpenSceneGraph|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, <tt>download_and_compile.sh</tt> 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 <code>-s</code>) or the latest Long Term Stable release (option <code>--lts</code>) 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 <code>--lts</code>; for instance, in July 2020, <code>--lts</code> didn't build with OpenSceneGraph 3.6, but simply passing the OSG component on the <tt>download_and_compile.sh</tt> command solved the problem, because at that time, option <code>--lts</code> 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_lists|mailing list]] in case a problem popped up<ref name="what-to-provide-when-asking-for-help">Don't forget in this case to precisely tell what you did and include the <tt>compilation_log.txt</tt> file written by <tt>download_and_compile.sh</tt>.</ref> 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 <code>-s</code>) or the latest Long Term Stable release (option <code>--lts</code>). In case you want something even older, the previous LTS release can be selected with option <code>--old-lts</code>.}}

== 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|Getting started with <tt>download_and_compile.sh</tt>]].}}

=== Selecting the components to build ===

By default, <tt>download_and_compile.sh</tt> downloads or updates, then compiles, [[SimGear]], FlightGear, [[FGData]] and [[OpenSceneGraph|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 <tt>download_and_compile.sh</tt> 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 [https://cmake.org/ CMake] in <tt>download_and_compile.sh</tt>'s terminology.

A [[#list-of-available-components|list of available components]] is provided on this page, but the fully up-to-date list can always be obtained by running <code>download_and_compile.sh --help</code>.

=== Choosing between stable and development versions ===

By default, <tt>download_and_compile.sh</tt> 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 <code>-s</code>, <code>--lts</code> and <code>--old-lts</code> 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]], <code>-s</code> uses the most recent stable release branch of the corresponding Git repository, <code>--lts</code> uses the most recent Long Term Stable release (LTS) and <code>--old-lts</code> uses the previous LTS release.
* For other components, a known-stable version is selected by <tt>download_and_compile.sh</tt>, which may be influenced by the use of <code>-s</code>, <code>--lts</code> or <code>--old-lts</code>.

So, as far as the SIMGEAR, FGFS and DATA components are concerned, you can:
* build the latest stable release (<code>-s</code>);
* build the latest Long Term Stable release (<code>--lts</code>);
* build the previous Long Term Stable release (<code>--old-lts</code>);
* build the current development version (bleeding edge), which lives in the {{flightgear source
| branch = next
| text = next
}} branch of the FlightGear repository.
The use of <code>-s</code>, <code>--lts</code> or <code>--old-lts</code> also influences the version of other components you may have selected (this can be overridden using <code>--component-branch</code> for advanced users—see [[#Component-specific settings|Component-specific settings]]).

{{Note|In a given folder where <tt>download_and_compile.sh</tt> is run, you should normally either always use the <code>-s</code> option, or always use <code>--lts</code>, or always use <code>--old-lts</code>, 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 <code>--cleanup</code> option when doing the switch (see [[#Cleaning built and installed files|Cleaning built and installed files]] for information on this option). For instance:
* Build with <code>-s</code> as many times as you want.
* Want to try ''next''? Okay, then build once with <code>--cleanup</code> (no <code>-s</code> option anymore).
* You can then perform as many builds of ''next'' as you want; no need to use <code>--cleanup</code> unless something special went wrong.
* If you later decide to switch back to the stable release, build once with <code>-s</code> and <code>--cleanup</code>, then only with <code>-s</code> 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 <tt>download_and_compile.sh</tt>, use the <code>--lts</code> 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 [[#selecting-the-components-to-work-on | above]].)

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

==== Building the latest stable release of FlightGear ====

When executing <tt>download_and_compile.sh</tt>, use the <code>-s</code> option to build the latest stable release:
$ cd ~/flightgear/dnc-managed
$ download_and_compile.sh -s

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

==== Building the current FlightGear development version ====

When executing <tt>download_and_compile.sh</tt> 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 <tt>download_and_compile.sh</tt>, use the <code>--old-lts</code> 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 [[#selecting-the-components-to-work-on | above]].)

{{Note|If you decide to use the <code>--old-lts</code> option in a given directory tree, you should use it for all components in that directory tree (SIMGEAR, FGFS, DATA, etc.). Running <tt>download_and_compile.sh</tt> in a given directory with the <code>--old-lts</code> 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 <tt>fgfs-osg-36-2</tt> of the Git repository located at [https://gitlab.com/flightgear/openscenegraph.git https://gitlab.com/flightgear/openscenegraph.git] (this is actually the default in September 2024). Since the default protocol used when <tt>download_and_compile.sh</tt> clones a repository is [https://en.wikipedia.org/wiki/HTTPS 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 ====

<tt>download_and_compile.sh</tt> uses case-insensitive short names such as <tt>GitHub</tt>, <tt>SourceForge</tt> and <tt>gitlab.kitware.com</tt> 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 <code>download_and_compile.sh --help</code>, in particular in the <tt>--git-clone-site-params</tt> and <tt>--override-repo</tt> options we'll present below. These ''site'' keys are simply identifier strings; they are not used in the DNS queries.

==== The protocol ====

Current <tt>download_and_compile.sh</tt> (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 <tt>wget</tt> and are out-of-scope for this section.

The default protocol used by <tt>download_and_compile.sh</tt> when cloning a Git repository is [https://en.wikipedia.org/wiki/HTTPS HTTPS]. This can be overridden using the <tt>--git-clone-default-proto</tt> option. In other words, the default is <tt>--git-clone-default-proto=https</tt> (the protocol name is case-insensitive). Other possibilities for the protocol are <tt>git</tt> and <tt>ssh</tt>.

{{Warning|The <tt>git</tt> 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 <tt>ssh</tt> protocol as the argument of <tt>--git-clone-default-proto</tt> 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, <tt>~/.ssh/config</tt> can be used to automatically provide a site-dependent username). That is why <tt>download_and_compile.sh</tt> offers the <tt>--git-clone-site-params</tt> option.

==== Site-specific settings ====

Using
--git-clone-site-params ''SITE''=''PROTOCOL''[:''USERNAME'']
you can tell <tt>download_and_compile.sh</tt> that every component fetched from ''SITE'' should be cloned with the specified protocol and username (allowed protocols are <tt>https</tt>, <tt>ssh</tt> and <tt>git</tt>).

{{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:
<pre>
--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</pre>
Here, the site names are <tt>GitHubA</tt> and <tt>GitHubB</tt>; the <tt>--override-repo</tt> option will be presented below.

By default, <tt>download_and_compile.sh</tt> case-insensitively uses the <tt>GitHub</tt> (resp. <tt>SourceForge</tt>) 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''<nowiki>=</nowiki>GitHubA:... or --override-repo ''c''<nowiki>=</nowiki>GitHubB:... has been specified.}}

==== Component-specific settings ====

The <tt>--override-repo</tt> and <tt>--component-branch</tt> options allow one to override the default settings used by <tt>download_and_compile.sh</tt> 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 <tt>download_and_compile.sh</tt> (e.g., <tt>SIMGEAR</tt>—see [[#List of available components|List of available components]]);
* ''ADDRESS'' is something like <tt>git.code.sf.net/p/flightgear/simgear</tt> (don't include any <tt>protocol://</tt> 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; <tt>download_and_compile.sh</tt> uses it to find out how to connect to ''ADDRESS'' in order to clone the repository for ''COMPONENT'' (see [[#Site-specific settings|Site-specific settings]]).
See the [[#A short example|above example]] for a concrete example where these options are used.

{{Note|The argument of any long option of <tt>download_and_compile.sh</tt> 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 <tt>download_and_compile.sh</tt> (October 2020 or later), this can be done for SimGear and FlightGear using the <code>--sg-cmake-arg</code> and <code>--fg-cmake-arg</code> options (the environment variables <tt>SG_CMAKEARGS</tt> and <tt>FG_CMAKEARGS</tt> 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 <tt>CMakeLists.txt</tt> files, for example {{simgear source
| path = CMakeLists.txt
| text = here
}} for SimGear and {{flightgear source
| path = CMakeLists.txt
| text = 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 {{forum link|t=35740|text=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 <code>--sg-cmake-arg</code> and/or <code>--fg-cmake-arg</code> 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 <code>$(...)</code> command substitution.

Using the (half-deprecated) environment variables <tt>SG_CMAKEARGS</tt> and <tt>FG_CMAKEARGS</tt>, 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 <tt>download_and_compile.sh</tt>, 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 <tt>download_and_compile.sh</tt>, 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 <tt>download_and_compile.sh</tt> 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 <tt>download_and_compile.sh</tt> in the directory where it is run, such as <tt>run_fgfs.sh</tt> and <tt>run_fgfs_debug.sh</tt>: these scripts automatically set up the required environment variables according to your build settings before firing the desired program (e.g., <tt>fgfs</tt>) with the arguments you provided.

Therefore, the simplest way to run a FlightGear program built by <tt>download_and_compile.sh</tt> is to launch the <tt>run_fgfs.sh</tt> script that <tt>download_and_compile.sh</tt> created in the directory from which it was run, for example:
$ cd ~/flightgear/dnc-managed
$ ./run_fgfs.sh --launcher

{{Note|<code>./run_fgfs.sh --launcher</code> starts FlightGear with its built-in launcher. If you just do <code>./run_fgfs.sh</code>, 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, [https://en.wikipedia.org/wiki/Paro_Airport 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 <tt>download_and_compile.sh</tt> to maintain several directory trees such as the tree starting at <tt>~/flightgear/dnc-managed</tt> in [[#getting-started-with-download-and-compile-sh|Getting started with <tt>download_and_compile.sh</tt>]] (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 <tt>download_and_compile.sh</tt> 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 <tt>~/flightgear/dnc-managed/install/flightgear/fgdata</tt>. 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 <tt>~/flightgear/dnc-managed/install/flightgear/fgdata</tt>.

{{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 [[Avoiding multiple downloads of FGData on Linux|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|Getting started with <tt>download_and_compile.sh</tt>]].}}

If you wish to get other programs (precisely: download, build and install them), you need to launch <tt>download_and_compile.sh</tt> with the desired component names as arguments. For instance:
$ cd ~/flightgear/dnc-managed
$ download_and_compile.sh SIMGEAR FGFS DATA OSG

See [[#list-of-available-components|above]] for the list of available components.

=== TerraGear ===

Run <tt>download_and_compile.sh</tt> 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 <tt>~/flightgear/dnc-managed</tt>:
* <tt>run_genapts850.sh</tt>
* <tt>run_ogr-decode.sh</tt>
* <tt>run_tg-construct.sh</tt>
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 <tt>download_and_compile.sh</tt> with the TERRAGEARGUI component:
$ cd ~/flightgear/dnc-managed
$ download_and_compile.sh TERRAGEARGUI
This will create a <tt>run_terrageargui.sh</tt> script in <tt>~/flightgear/dnc-managed</tt>, and also a default configuration file <tt>~/.config/TerraGear/TerraGearGUI.conf</tt>, 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 <tt>download_and_compile.sh</tt> to take care of the FGFS component. You can launch the standalone FGCom program by using the <tt>run_fgcom.sh</tt> script:
$ cd ~/flightgear/dnc-managed
$ ./run_fgcom.sh

=== FGRun ===

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

[[File:fgrun-page2.jpg|thumb|right]]
Before FlightGear had its built-in launcher (the one you get with <code>run_fgfs.sh --launcher</code>), many users found comfortable having FlightGear launched by the graphical utility [[Fgrun|FGRun]]. This program is built and installed when <tt>download_and_compile.sh</tt> is run with the FGRUN component. You then have to launch the <tt>run_fgrun.sh</tt> command, for example:
$ cd ~/flightgear/dnc-managed
$ ./run_fgrun.sh

FGRun will save its settings in <tt>~/.fltk/flightgear.org/fgrun.prefs</tt>. 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 <code>run_fgfs.sh --launcher</code>) or [[FFGo]].}}

[[File:Fgo01.jpg|thumb|left]]
FGo! is a graphical utility written in [[python]]. It is downloaded and installed when <tt>download_and_compile.sh</tt> is run with the FGO component. You then have to launch the <tt>run_fgo.sh</tt> 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 <tt>fgfs</tt> 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:
# 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.
# 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.
# 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|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 <tt>download_and_compile.sh</tt> 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 <tt>download_and_compile.sh</tt> script to clean OpenRTI with <code>rm -f CMakeCache.txt && rm -rf CMakeFiles/</code>, or just restart the build in a clean environment. Assuming you are in the base directory from which you ran <tt>download_and_compile.sh</tt>, you can run <code>download_and_compile.sh --cleanup</code> (see [[#Cleaning built and installed files|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 {{forum link|t=26244|text=this thread}} for more details. Note that <tt>download_and_compile.sh</tt> didn't have the <code>--cleanup</code> option at that time!

== Options ==

=== Release selection ===

* Build the latest stable release: <code>-s</code>
* Build the latest Long Term Stable release: <code>--lts</code>
* Build the previous Long Term Stable release: <code>--old-lts</code>

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

If you pass none of <code>-s</code>, <code>--lts</code> and <code>--old-lts</code> in a <tt>download_and_compile.sh</tt> 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, <tt>download_and_compile.sh</tt> 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 <code>--non-interactive</code> option in order to suppress these prompts (technically, this causes the default answer to be automatically used).

=== Cleaning built and installed files ===

Option <code>--cleanup</code> causes <tt>download_and_compile.sh</tt> 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 <code>--cleanup</code> 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 <code>-j x</code> to <tt>download_and_compile.sh</tt> (where ''x'' is the number of your CPU cores you wish to assign to the job) will considerably speed up the compilation steps. Passing <code>-j$(nproc)</code> is a convenient way to automatically use all available cores.

=== Advanced options ===

* Build a release version: <code>-b Release</code>
* Build a version that should run as fast as a release build, yet has debug information that can be used to post backtraces: <code>-b RelWithDebInfo</code> (this is the default)
* Build a full debug version for very complete bug reporting: <code>-b Debug</code>
* Skip download of distro packages (i.e., by default: <tt>apt-get install ...</tt>): <code>-p n</code>
* Skip retrieving of component downloads and updates (which typically use Git or wget): <code>-d n</code>
* Skip the configure step (like running [https://cmake.org/ CMake] or [https://www.gnu.org/software/autoconf/ autoconf]'s <tt>./configure</tt>): <code>-r n</code>
* Skip compilation of programs: <code>-c n</code>
* Build with compositor: <code>--compositor</code>
* Force the use of a particular branch for a given component: <code>--component-branch ''COMPONENT=BRANCH''</code> (e.g., <code>--component-branch OSG=OpenSceneGraph-3.6</code>, <code>--component-branch FGFS=next</code>, etc.—but remember that components FGFS, SIMGEAR and DATA must ''always'' be in sync). See [[#Component-specific settings|Component-specific settings]] for details.
* Override the repository from which a given component is initially fetched: <code>--override-repo ''COMPONENT''=''SITE'':''ADDRESS''</code> (see [[#Component-specific settings|Component-specific settings]]).
* Generate build.ninja files and build using Ninja: <code>-G Ninja</code>
* Run CMake in verbose mode: <code>--verbose</code> (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 <code>-rn</code> option may be necessary, though (this is the case in particular if you added or removed C++ files).

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

Export in environment:
export CMAKE_CXX_COMPILER_LAUNCHER=ccache

Or when running <code>download_and_compile.sh</code> add this option (does not work on 2024.1, but works with -next branch):
--cmake-arg=ALL="-DCMAKE_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 <tt>download_and_compile.sh</tt>):
$ sed 's|\./fgfs|optirun ./fgfs|' run_fgfs.sh > run_fgfs_optirun.sh && chmod +x run_fgfs_optirun.sh
Now you can run FlightGear with <code>./run_fgfs_optirun.sh</code>.

The same can be done for the [[FlightGear_Launch_Control|FGRun]] launcher:
$ sed 's|\./fgrun|optirun ./fgrun|' run_fgrun.sh > run_fgrun_optirun.sh && chmod +x run_fgrun_optirun.sh

== See also ==

* {{fgmeta source
| path = compile-scripts
| text = Other FlightGear build scripts
}} present in [[FGMeta]]
* {{fgmeta source
| path = fg-from-scratch
| simplepath = true
}}
* [http://geoffmclane.com/fg/fgfs-052.htm Another script] for building FlightGear and all its dependencies in an automated fashion. The page seems a bit oldish, though (as of 2019).

== References ==
<references/>

[[Category:Building from source]]

[[fr:Script de compilation sous Linux Debian/Ubuntu]]
[[nl:Compileren met een Script op Linux Debian/Ubuntu]]

Scripted Compilation on Linux Debian/Ubuntu

2024-12-24T20:12:43Z

Jebba: /* ccache */ --cmake-arg only with -next

<tt>download_and_compile.sh</tt> 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<ref name="just-one-command">Due to technical problems on the [https://sourceforge.net/ SourceForge] side, this is currently only true once you have an [[FGData]] clone. See [[User:Rominet|here]] for details.</ref> for both 32-bit and 64-bit [https://www.debian.org/ Debian]-based systems. Pre-existing versions (if any) of the software installed by <tt>download_and_compile.sh</tt> 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, <tt>download_and_compile.sh</tt> installs packages with <tt>apt-get</tt>. For this reason, it is primarily useful on Debian-based distributions. However, if one disables package installation (using <code>-pn</code> or <code>--sudo=echo</code>) 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 [https://www.openbsd.org/ OpenBSD].

For hints on using <tt>rpm</tt>-based distributions such as Redhat, Fedora and CentOS, please see [[CentOS]]. Please also see [[Superbuild]].

== Introduction ==

<tt>download_and_compile.sh</tt> is a [https://www.gnu.org/software/bash/ Bash] script written for [https://www.debian.org/ Debian]-derived distributions ([https://www.ubuntu.com/ Ubuntu], [https://devuan.org/ Devuan], [https://www.linuxmint.com/ Linux Mint], etc.). Its purpose is to automatically install dependencies using the package manager, then build and install FlightGear-related programs.

By default, <tt>download_and_compile.sh</tt> installs most dependencies with <tt>apt-get</tt> run under <tt>sudo</tt>.<ref name="disabling-installation-of-dependencies-via-package-manager">If you think you already have the dependencies, this installation can be disabled either by using option <code>-pn</code> or by passing option <code>--sudo=echo</code> (the latter results in printing the <tt>apt-get</tt> command line without running it).</ref> Other dependencies, either because they aren't available in the standard APT repositories, or because of non-option arguments passed to <tt>download_and_compile.sh</tt>, 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).

<tt>download_and_compile.sh</tt> works in the directory it is run from: apart from dependencies installed via the package manager, all programs built by <tt>download_and_compile.sh</tt> are installed under the <tt>install</tt> subdirectory of the directory from which the script was run. In other words, installation of programs by <tt>download_and_compile.sh</tt> 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 <tt>download_and_compile.sh</tt>; as far as it is concerned, such directory trees are completely independent from each other. For instance, if you run <tt>download_and_compile.sh</tt> in <tt>dir1</tt> and <tt>dir2</tt>, the programs installed under <tt>dir1</tt> won't “see” those installed under <tt>dir2</tt>, and vice versa.

Apart from its main purpose, <tt>download_and_compile.sh</tt> can be used to find hopefully up-to-date build-dependency information for FlightGear and related software. You would do so by inspecting [https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/download_and_compile.sh the script] at the point where it installs packages.<ref name="note-inspecting-download-and-compile-sh-to-gather-build-dependency-information">Look for strings such as <tt>zlib1g-dev</tt>, <tt>libglew-dev</tt> or <tt>qt5-default</tt>.</ref>

== Prerequisites ==

Before embarking on building your own FlightGear binaries, you need to install a few tools that <tt>download_and_compile.sh</tt> uses to retrieve and compile source code. These tools are found in the following packages on [https://www.debian.org/ 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 <tt>download_and_compile.sh</tt> 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 [https://en.wikipedia.org/wiki/Gibibyte 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 <code>-j8</code> 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 <tt>download_and_compile.sh</tt> {{fgmeta source
| path = download_and_compile.sh
| text = 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 <code>download_and_compile.sh --version</code> work as intended, it is recommended to get it as explained [[#getting-download-and-compile-sh-using-an-fgmeta-clone|below]].

In case you build stable versions of FlightGear using either of the <code>-s</code>, <code>--lts</code> and <code>--old-lts</code> options of <tt>download_and_compile.sh</tt>, remember to update the script before trying to build a new version of FlightGear (see [[#updating-download-and-compile-sh-using-an-fgmeta-clone|Updating <tt>download_and_compile.sh</tt>]] 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 <tt>download_and_compile.sh</tt> ==

=== 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 <code>-pn</code> or something similar to disable installation of packages from your distribution, you'll be asked for your <tt>sudo</tt> password during execution of the <tt>download_and_compile.sh</tt> command (<tt>sudo</tt> is used by <tt>download_and_compile.sh</tt> to run commands like <tt>apt-get</tt>). So, here is your quick recipe for getting <tt>download_and_compile.sh</tt> and using it to build FlightGear:
mkdir -p ~/flightgear/dnc-managed
cd ~/flightgear
<nowiki>git clone https://git.code.sf.net/p/flightgear/fgmeta</nowiki>
cd ~/flightgear/dnc-managed
~/flightgear/fgmeta/download_and_compile.sh -s -j$(nproc)
./run_fgfs.sh --launcher

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

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

In some cases, <tt>download_and_compile.sh</tt> 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 <code>--non-interactive</code> option to suppress them.

More detailed instructions are given below. The following sections also explain how to update <tt>download_and_compile.sh</tt> 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:
* <tt>~/flightgear/fgmeta</tt> will contain a clone of the [[FGMeta]] repository; therefore, <tt>download_and_compile.sh</tt> will reside in that directory;
* <tt>~/flightgear/dnc-managed</tt> will be the directory from which we run <tt>download_and_compile.sh</tt>. 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 <tt>download_and_compile.sh</tt> the “right way” ===

There are several ways to obtain [https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/download_and_compile.sh download_and_compile.sh]. The method described here makes it very easy to update the script and causes the command <code>download_and_compile.sh --version</code> to work as intended.

As explained in [[#getting-started-with-download-and-compile-sh-notations|Notations]], we want to clone the [[FGMeta]] repository in <tt>~/flightgear/fgmeta</tt> and work with its ''next'' branch. Let's go:
$ mkdir -p ~/flightgear
$ cd ~/flightgear
<nowiki>$ git clone -b next https://git.code.sf.net/p/flightgear/fgmeta</nowiki>
You now have a fresh FGMeta clone in <tt>~/flightgear/fgmeta</tt> and your brand new <tt>download_and_compile.sh</tt> script is located in that directory. You can already try it to see the available options:
<pre>$ ~/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

(...)</pre>

=== Updating <tt>download_and_compile.sh</tt> ===

Now that you have <tt>download_and_compile.sh</tt> from the [[FGMeta]] repository, it is very easy to update (this assumes you didn't modify anything yourself inside <tt>~/flightgear/fgmeta</tt>!):
$ cd ~/flightgear/fgmeta && git pull

If you want to keep updates as easy as we just showed, it is best not to modify <tt>download_and_compile.sh</tt> yourself. <tt>download_and_compile.sh</tt> has plenty of options that usually make it unnecessary to modify the script. Just run <code>download_and_compile.sh --help</code> 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 <tt>download_and_compile.sh</tt>, you are invited to skip to the next section.

If you really, ''really'' want to modify <tt>download_and_compile.sh</tt> 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 <code>git status</code>), 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 <tt>download_and_compile.sh</tt>. 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 <tt>download_and_compile.sh</tt> when showing commands to be run, but you should prepend it to <tt>download_and_compile.sh</tt> whenever you see a <tt>download_and_compile.sh</tt> command. For instance, if you used the same path as in [[#getting-started-with-download-and-compile-sh-notations|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 <tt>download_and_compile.sh</tt> commands from an arbitrary directory, in particular ''don't'' run them from <tt>~/flightgear/fgmeta</tt>. This is because '''most other <tt>download_and_compile.sh</tt> commands write to the current directory''' (<code>download_and_compile.sh --help</code> and <code>download_and_compile.sh --version</code> 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 [https://sourceforge.net/p/flightgear/mailman/message/36634426/ this message]), by adding the directory containing <tt>download_and_compile.sh</tt> to your <tt>PATH</tt> or by creating a symbolink link pointing to <tt>download_and_compile.sh</tt> in a directory that is part of your <tt>PATH</tt>. 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 <tt>PATH</tt>).

{{Note|The following commands should be run from an empty directory<ref name="dedicated-directory-won-t-stay-empty-forever">Well, empty before the first time; later, <tt>download_and_compile.sh</tt> is going to populate it with plenty of FlightGear files and subdirectories, of course.</ref> in a partition that has enough free space (see [[#disk-space-requirements-and-build-time | Disk space requirements and build time]]). As explained in [[#getting-started-with-download-and-compile-sh-notations|Notations]], we are going to choose the directory <tt>~/flightgear/dnc-managed</tt> for this purpose, in order to express that the whole directory tree is managed by <tt>download_and_compile.sh</tt>. 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 <tt>download_and_compile.sh</tt> 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, <tt>download_and_compile.sh</tt> may use <tt>sudo</tt>. In case you want to run some other program instead of <tt>sudo</tt>, this can be done with the <code>--sudo</code> option of <tt>download_and_compile.sh</tt>. For instance, in order to see the commands that would be run with sudo without actually running them, you can pass <code><nowiki>--sudo=echo</nowiki></code> to <tt>download_and_compile.sh</tt>. Like all other options, <code>--sudo</code> must be given ''before'' all arguments that are component names (such as <tt>SIMGEAR</tt>, <tt>FGFS</tt>, <tt>DATA</tt>, etc.).}}

The package manager used by <tt>download_and_compile.sh</tt> by default is <tt>apt-get</tt> (it won't be used if you pass <tt>download_and_compile.sh</tt> the <code>-pn</code> 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 <tt>aptitude</tt> as well as <tt>apt</tt>. If you want <tt>download_and_compile.sh</tt> to use <tt>aptitude</tt>, give it the option <code><nowiki>--package-manager=aptitude</nowiki></code> before any of the ''COMPONENT'' arguments.

All options of <tt>download_and_compile.sh</tt> 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 <tt>download_and_compile.sh</tt> will be stored. This is <tt>~/flightgear/dnc-managed</tt> if you followed the suggestions given in [[#getting-started-with-download-and-compile-sh-notations|Notations]], and should be empty before you run <tt>download_and_compile.sh</tt> for the first time. However, it is quite correct to start <tt>download_and_compile.sh</tt> from the same directory for subsequent runs, even when non-empty (otherwise, <tt>download_and_compile.sh</tt> 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 <code>-j$(nproc)</code> 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| Multicore acceleration]].

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

When you don't pass any non-option argument to <tt>download_and_compile.sh</tt> as done here, it takes care of the base components needed to run FlightGear in good conditions: <tt>SIMGEAR</tt>, <tt>FGFS</tt>, <tt>DATA</tt> and <tt>OSG</tt> (these are the component names used by <tt>download_and_compile.sh</tt>, i.e., the final arguments one can optionally give in a <tt>download_and_compile.sh</tt> command; in normal speech, they correspond to the {{simgear source
| text = SimGear
}}, {{flightgear source
| text = FlightGear
}} and {{fgdata source
| text = 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 <tt>run_fgfs.sh</tt> in the directory from which you ran <tt>download_and_compile.sh</tt> (i.e., <tt>~/flightgear/dnc-managed</tt> in the suggested setup). This will be your script to run FlightGear. For instance, in order to start the [[FlightGear Qt launcher|built-in launcher]], you can run the following commands:<ref name="no-need-to-change-to-dnc-managed-dir-before-starting-generated-scripts">We give these commands because they are easy to read, but the <code>cd</code> command is not needed if you use the correct path, as in <code>~/flightgear/dnc-managed/run_fgfs.sh --launcher</code>.</ref>
$ cd ~/flightgear/dnc-managed
$ ./run_fgfs.sh --launcher
(You may omit the <code>--launcher</code> 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 [https://sourceforge.net/p/flightgear/mailman/message/36634426/ this message] or use another launcher such as [[FFGo]]—but the [[FlightGear Qt launcher|FlightGear built-in launcher]] started with <code>run_fgfs.sh --launcher</code> is quite fine, be sure to try it first!

{{Note|If you ran <tt>download_and_compile.sh</tt> from <tt>~/flightgear/dnc-managed</tt> as proposed above, the full path of the <tt>~/flightgear/dnc-managed/install/flightgear/fgdata</tt> 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 <code>-s</code>, <code>--lts</code> and <code>--old-lts</code>, you need to pass the ''same option'' to the <tt>download_and_compile.sh</tt> command given below that will update your FlightGear installation. Otherwise, <tt>download_and_compile.sh</tt> 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 <code>--cleanup</code> option of <tt>download_and_compile.sh</tt> is heartily recommended.}}

Keeping the above note in mind, go to the directory from which you previously ran <tt>download_and_compile.sh</tt> (<tt>~/flightgear/dnc-managed</tt> in the [[#Notations|suggested setup]]). This is the folder which, if you did a complete run of <tt>download_and_compile.sh</tt> as shown in the previous section, contains the <tt>run_fgfs.sh</tt> script and a log file named <tt>compilation_log.txt</tt> that records what <tt>download_and_compile.sh</tt> did in its last run. If you wish to update, say, {{simgear source
| text = SimGear
}}, {{flightgear source
| text = FlightGear
}}, {{fgdata source
| text = FGData
}} and [[OpenSceneGraph|OSG]], simply execute this:
$ download_and_compile.sh -pn -j$(nproc) SIMGEAR FGFS DATA OSG
The <code>-j$(nproc)</code> 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| Multicore acceleration]].

We'll explain the <code>-pn</code> in a minute. <tt>SIMGEAR</tt>, <tt>FGFS</tt>, <tt>DATA</tt> and <tt>OSG</tt> are called ''components'' in <tt>download_and_compile.sh</tt> terminology. A component generally corresponds to a software repository, or something close. In fact, since <tt>SIMGEAR</tt>, <tt>FGFS</tt>, <tt>DATA</tt> and <tt>OSG</tt> 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 <code>-pn</code>. It is equivalent to <code>-p n</code> and means “don't install packages from my (Linux) distribution” (<code>y</code> means ''yes, please install'', <code>n</code> means ''no, don't install''). In case you forgot that, simply run:
$ download_and_compile.sh --help
What does it imply to pass <code>-pn</code>? This tells <tt>download_and_compile.sh</tt> to completely skip the step where it checks for needed packages from your distribution and installs them, by default using <tt>apt-get</tt>. It thus goes straight to the following steps:
* update each repository corresponding to one of the selected components (<tt>SIMGEAR</tt>, <tt>FGFS</tt>, <tt>DATA</tt> and <tt>OSG</tt> in our example);
* compile each selected component that requires compilation;
* install each selected component in the appropriate place (under <tt>~/flightgear/dnc-managed</tt> according to our [[#getting-started-with-download-and-compile-sh-notations|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 <code>-pn</code> to <tt>download_and_compile.sh</tt>, you forbid it to install these dependencies for you. So, you can also very well update without passing the <code>-pn</code> option, it will simply take a little longer (the time to check if all dependencies of the selected components are available with <tt>APT</tt>). In fact, this is '''what you should do if the previous <tt>download_and_compile.sh</tt> run failed:''' first update <tt>download_and_compile.sh</tt> (see [[#getting-download-and-compile-sh-using-an-fgmeta-clone|above]]) then run it ''without'' <code>-pn</code><ref name="passing-no-pn-option-equals-passing-py">Which is the same as passing <code>-py</code>.</ref> 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 <code>download_and_compile.sh --cleanup</code> to restart the build from a clean state is probably a good idea (see [[#Cleaning built and installed files|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 <tt>download_and_compile.sh</tt> (see [[#getting-download-and-compile-sh-using-an-fgmeta-clone|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 <tt>SIMGEAR FGFS DATA OSG</tt> if you don't specify any.

=== Examining the history of <tt>download_and_compile.sh</tt> ===

Looking at the latest commits that affected <tt>download_and_compile.sh</tt> is quite easy with your FGMeta clone:
$ cd ~/flightgear/fgmeta
$ git log -- download_and_compile.sh
(then quit by typing <tt>q</tt>, assuming your <tt>$GIT_PAGER</tt> is <tt>less</tt>) 

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 [https://sourceforge.net/ SourceForge] infrastructure (namely, <code>git clone</code> from SourceForge doesn't work for the big FGData repository using https). Current versions of <tt>download_and_compile.sh</tt> avoid the problem by proposing the user to automatically clone FGData from its [https://gitlab.com/flightgear/fgdata 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 [https://sourceforge.net/ SourceForge] using the SSH protocol, you'll need an account on that site. If you don't already have one, go to the [https://sourceforge.net/user/registration 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 [[#getting-started-with-download-and-compile-sh-notations|Notations]], we assume that your Unix user name (login) is <tt>toto</tt>. Don't confuse the <tt>sudo</tt> password prompt (where you need to enter <tt>toto</tt>'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, <tt>download_and_compile.sh</tt> may use <tt>sudo</tt>. In case you want to run some other program instead of <tt>sudo</tt>, this can be done with the <code>--sudo</code> option of <tt>download_and_compile.sh</tt>. For instance, in order to see the commands that would be run with sudo without actually running them, you can pass <code><nowiki>--sudo=echo</nowiki></code> to <tt>download_and_compile.sh</tt>. Like all other options, <code>--sudo</code> must be given ''before'' all arguments that are component names (such as <tt>SIMGEAR</tt>, <tt>FGFS</tt>, <tt>DATA</tt>, 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 <code>-s</code> or <code>--lts</code> to all <tt>download_and_compile.sh</tt> commands given below (or <code>--old-lts</code> for the previous LTS release). You may add the chosen option right after the <tt>download_and_compile.sh</tt> command name (in any case, the option should come before non-option arguments such as SIMGEAR, FGFS, DATA, etc.). See [[#Release selection|Release selection]] for more explanations on options <code>-s</code>, <code>--lts</code> and <code>--old-lts</code>.}}

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

Ready? Let's go!
<pre>$ 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.
</pre>

The above messages are perfectly normal but deserve a little explanation. Here, <tt>ssh</tt> asked us to confirm that the fingerprint sent by the remote host is that of the real <tt>git.code.sf.net</tt>, as opposed to that of some malicious server ''pretending'' to be <tt>git.code.sf.net</tt>. This confirmation only has to be done once, after which it is remembered thanks to <tt>~/.ssh/known_hosts</tt>. You should visit the [https://sourceforge.net/p/forge/documentation/SSH%20Key%20Fingerprints/#fingerprint-listing 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 <tt>git.code.sf.net</tt>, or some matching pattern such as <tt>*.code.sf.net</tt>.

If the fingerprint that is printed on your terminal is not listed on that page, answer <tt>no</tt> 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 <tt>ssh</tt> that contains the fingerprint sent to you by the remote host which pretends to be <tt>git.code.sf.net</tt>. 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 <tt>yes</tt> 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 <tt>git.code.sf.net</tt> server and confirm it to <tt>ssh</tt>. Because of this delay, <tt>git.code.sf.net</tt> hung up on us and closed the connection. This is absolutely ''not a problem:'' we can just rerun the <tt>download_and_compile.sh</tt> command with the same arguments as the first time. Since we answered <tt>yes</tt> to the ''Are you sure you want to continue connecting (yes/no)?'' prompt, the fingerprint of <tt>git.code.sf.net</tt>'s key has been stored in <tt>~/.ssh/known_hosts</tt>, therefore we won't get this prompt anymore. But if some server claiming to be <tt>git.code.sf.net</tt> presents a host key that has a different fingerprint in the future, <tt>ssh</tt> will print a big fat warning that the server may belong to an attacker trying to impersonate <tt>git.code.sf.net</tt>. 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 <tt>download_and_compile.sh</tt> command with the same arguments:
<pre>$ 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:</pre>
As explained above, the preceding prompt is for your SourceForge password (which you could guess from the <code><nowiki>git clone ssh://SFusername@git.code.sf.net/p/flightgear/fgdata</nowiki></code> command).
<pre>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:</pre>
(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 <tt>download_and_compile.sh</tt> wants to run <code>git pull --rebase</code> in the repository (admittedly, it's a bit dumb after a <tt>clone</tt> operation—please forgive us). In case you were not monitoring the <tt>clone</tt> operation, you probably saw the password prompt way after <tt>git.code.sf.net</tt> got bored waiting for you and closed our second connection:
<pre>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.</pre>
(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:
<pre>$ 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.
</pre>
There we are! You now have a clean, up-to-date [[FGData]] clone in <tt>~/flightgear/dnc-managed/install/flightgear/fgdata</tt> (remember: <tt>~/flightgear/dnc-managed</tt> is the directory from which you ran <tt>download_and_compile.sh</tt>). Note this place: the full path of the <tt>~/flightgear/dnc-managed/install/flightgear/fgdata</tt> directory is your [[$FG_ROOT]].

Now, change the protocol to use for future updates of your FGData clone:<ref name="changing-the-protocol-for-a-git-remote-manual-method">Another way would be to manually change the relevant line starting with <code>url = <nowiki>ssh://SFusername@</nowiki></code> for the <code>origin</code> remote in the <tt>.git/config</tt> file that lives inside your repository clone (i.e., <tt>~/flightgear/dnc-managed/install/flightgear/fgdata/.git/config</tt> in our example).</ref>
(cd install/flightgear/fgdata && \
git remote set-url origin <nowiki>https://git.code.sf.net/p/flightgear/fgdata</nowiki>)
(you can check at any time the protocol(s) in use with the command <code>git remote -v</code> run inside a Git repository—in this case, inside the folder <tt>install/flightgear/fgdata</tt>). As a consequence of this change, all future updates of your FGData clone will use the <tt>https</tt> 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 (<tt>~/flightgear/dnc-managed</tt> in our example):
$ download_and_compile.sh -j$(nproc)
The <code>-j$(nproc)</code> 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| Multicore acceleration]].

Assuming the compilation was successful, you can now start the [[FlightGear Qt launcher|FlightGear built-in launcher]] using for instance:
$ ./run_fgfs.sh --launcher
See [[#Building FlightGear|Building FlightGear]] for more details.

== List of available components ==

The <tt>download_and_compile.sh</tt> 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 [https://cmake.org/ 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|FGRun]] FlightGear launcher)
* FGX (for the [[FGX|FGx]] FlightGear launcher<ref name="note-on-the-status-of-FGx-support-in-download-and-compile-sh">Support for FGx in <tt>download_and_compile.sh</tt> would probably benefit from a code review.</ref>)
* OPENRADAR (for the [[OpenRadar]] air traffic control simulation program)
* OPENRTI (for [[FlightGear HLA support (High Level Architecture)#OpenRTI | OpenRTI]]<ref name="note-on-the-status-of-OpenRTI-support-in-FG">Note that OpenRTI is just an optional dependency for [[FlightGear high-level architecture support | HLA support]]. For the time being, you should be just fine building without it. Eventually, the idea is for HLA to replace the existing MP system and even increasingly distribute the FlightGear architecture such that more and more components can be more easily run in separate threads or even separate processes, possibly even on different machines. So this is going to be an important feature for professional users, using several computers and screens to create a comprehensive and immersive simulation environment.

At the moment, it is probably safe to say that HLA is only of interest to developers and people willing to play with experimental features.</ref>)
* 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 [http://www.zlib.net/ zlib] compression library)

Each of the items listed above is a ''component'' in <tt>download_and_compile.sh</tt> 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 <tt>download_and_compile.sh</tt> can always be obtained by running <code>download_and_compile.sh --help</code>.}}

What is the point of knowing this? Because you may pass component names to <tt>download_and_compile.sh</tt> in order to tell it what you want to download, build and install. By default, only the components [[SimGear|SIMGEAR]], [[FlightGear|FGFS]], [[FGData|DATA]] and [[OpenSceneGraph|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, <tt>download_and_compile.sh</tt> 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 <code>-s</code>) or the latest Long Term Stable release (option <code>--lts</code>) 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 <code>--lts</code>; for instance, in July 2020, <code>--lts</code> didn't build with OpenSceneGraph 3.6, but simply passing the OSG component on the <tt>download_and_compile.sh</tt> command solved the problem, because at that time, option <code>--lts</code> 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_lists|mailing list]] in case a problem popped up<ref name="what-to-provide-when-asking-for-help">Don't forget in this case to precisely tell what you did and include the <tt>compilation_log.txt</tt> file written by <tt>download_and_compile.sh</tt>.</ref> 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 <code>-s</code>) or the latest Long Term Stable release (option <code>--lts</code>). In case you want something even older, the previous LTS release can be selected with option <code>--old-lts</code>.}}

== 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|Getting started with <tt>download_and_compile.sh</tt>]].}}

=== Selecting the components to build ===

By default, <tt>download_and_compile.sh</tt> downloads or updates, then compiles, [[SimGear]], FlightGear, [[FGData]] and [[OpenSceneGraph|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 <tt>download_and_compile.sh</tt> 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 [https://cmake.org/ CMake] in <tt>download_and_compile.sh</tt>'s terminology.

A [[#list-of-available-components|list of available components]] is provided on this page, but the fully up-to-date list can always be obtained by running <code>download_and_compile.sh --help</code>.

=== Choosing between stable and development versions ===

By default, <tt>download_and_compile.sh</tt> 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 <code>-s</code>, <code>--lts</code> and <code>--old-lts</code> 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]], <code>-s</code> uses the most recent stable release branch of the corresponding Git repository, <code>--lts</code> uses the most recent Long Term Stable release (LTS) and <code>--old-lts</code> uses the previous LTS release.
* For other components, a known-stable version is selected by <tt>download_and_compile.sh</tt>, which may be influenced by the use of <code>-s</code>, <code>--lts</code> or <code>--old-lts</code>.

So, as far as the SIMGEAR, FGFS and DATA components are concerned, you can:
* build the latest stable release (<code>-s</code>);
* build the latest Long Term Stable release (<code>--lts</code>);
* build the previous Long Term Stable release (<code>--old-lts</code>);
* build the current development version (bleeding edge), which lives in the {{flightgear source
| branch = next
| text = next
}} branch of the FlightGear repository.
The use of <code>-s</code>, <code>--lts</code> or <code>--old-lts</code> also influences the version of other components you may have selected (this can be overridden using <code>--component-branch</code> for advanced users—see [[#Component-specific settings|Component-specific settings]]).

{{Note|In a given folder where <tt>download_and_compile.sh</tt> is run, you should normally either always use the <code>-s</code> option, or always use <code>--lts</code>, or always use <code>--old-lts</code>, 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 <code>--cleanup</code> option when doing the switch (see [[#Cleaning built and installed files|Cleaning built and installed files]] for information on this option). For instance:
* Build with <code>-s</code> as many times as you want.
* Want to try ''next''? Okay, then build once with <code>--cleanup</code> (no <code>-s</code> option anymore).
* You can then perform as many builds of ''next'' as you want; no need to use <code>--cleanup</code> unless something special went wrong.
* If you later decide to switch back to the stable release, build once with <code>-s</code> and <code>--cleanup</code>, then only with <code>-s</code> 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 <tt>download_and_compile.sh</tt>, use the <code>--lts</code> 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 [[#selecting-the-components-to-work-on | above]].)

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

==== Building the latest stable release of FlightGear ====

When executing <tt>download_and_compile.sh</tt>, use the <code>-s</code> option to build the latest stable release:
$ cd ~/flightgear/dnc-managed
$ download_and_compile.sh -s

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

==== Building the current FlightGear development version ====

When executing <tt>download_and_compile.sh</tt> 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 <tt>download_and_compile.sh</tt>, use the <code>--old-lts</code> 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 [[#selecting-the-components-to-work-on | above]].)

{{Note|If you decide to use the <code>--old-lts</code> option in a given directory tree, you should use it for all components in that directory tree (SIMGEAR, FGFS, DATA, etc.). Running <tt>download_and_compile.sh</tt> in a given directory with the <code>--old-lts</code> 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 <tt>fgfs-osg-36-2</tt> of the Git repository located at [https://gitlab.com/flightgear/openscenegraph.git https://gitlab.com/flightgear/openscenegraph.git] (this is actually the default in September 2024). Since the default protocol used when <tt>download_and_compile.sh</tt> clones a repository is [https://en.wikipedia.org/wiki/HTTPS 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 ====

<tt>download_and_compile.sh</tt> uses case-insensitive short names such as <tt>GitHub</tt>, <tt>SourceForge</tt> and <tt>gitlab.kitware.com</tt> 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 <code>download_and_compile.sh --help</code>, in particular in the <tt>--git-clone-site-params</tt> and <tt>--override-repo</tt> options we'll present below. These ''site'' keys are simply identifier strings; they are not used in the DNS queries.

==== The protocol ====

Current <tt>download_and_compile.sh</tt> (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 <tt>wget</tt> and are out-of-scope for this section.

The default protocol used by <tt>download_and_compile.sh</tt> when cloning a Git repository is [https://en.wikipedia.org/wiki/HTTPS HTTPS]. This can be overridden using the <tt>--git-clone-default-proto</tt> option. In other words, the default is <tt>--git-clone-default-proto=https</tt> (the protocol name is case-insensitive). Other possibilities for the protocol are <tt>git</tt> and <tt>ssh</tt>.

{{Warning|The <tt>git</tt> 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 <tt>ssh</tt> protocol as the argument of <tt>--git-clone-default-proto</tt> 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, <tt>~/.ssh/config</tt> can be used to automatically provide a site-dependent username). That is why <tt>download_and_compile.sh</tt> offers the <tt>--git-clone-site-params</tt> option.

==== Site-specific settings ====

Using
--git-clone-site-params ''SITE''=''PROTOCOL''[:''USERNAME'']
you can tell <tt>download_and_compile.sh</tt> that every component fetched from ''SITE'' should be cloned with the specified protocol and username (allowed protocols are <tt>https</tt>, <tt>ssh</tt> and <tt>git</tt>).

{{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:
<pre>
--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</pre>
Here, the site names are <tt>GitHubA</tt> and <tt>GitHubB</tt>; the <tt>--override-repo</tt> option will be presented below.

By default, <tt>download_and_compile.sh</tt> case-insensitively uses the <tt>GitHub</tt> (resp. <tt>SourceForge</tt>) 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''<nowiki>=</nowiki>GitHubA:... or --override-repo ''c''<nowiki>=</nowiki>GitHubB:... has been specified.}}

==== Component-specific settings ====

The <tt>--override-repo</tt> and <tt>--component-branch</tt> options allow one to override the default settings used by <tt>download_and_compile.sh</tt> 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 <tt>download_and_compile.sh</tt> (e.g., <tt>SIMGEAR</tt>—see [[#List of available components|List of available components]]);
* ''ADDRESS'' is something like <tt>git.code.sf.net/p/flightgear/simgear</tt> (don't include any <tt>protocol://</tt> 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; <tt>download_and_compile.sh</tt> uses it to find out how to connect to ''ADDRESS'' in order to clone the repository for ''COMPONENT'' (see [[#Site-specific settings|Site-specific settings]]).
See the [[#A short example|above example]] for a concrete example where these options are used.

{{Note|The argument of any long option of <tt>download_and_compile.sh</tt> 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 <tt>download_and_compile.sh</tt> (October 2020 or later), this can be done for SimGear and FlightGear using the <code>--sg-cmake-arg</code> and <code>--fg-cmake-arg</code> options (the environment variables <tt>SG_CMAKEARGS</tt> and <tt>FG_CMAKEARGS</tt> 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 <tt>CMakeLists.txt</tt> files, for example {{simgear source
| path = CMakeLists.txt
| text = here
}} for SimGear and {{flightgear source
| path = CMakeLists.txt
| text = 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 {{forum link|t=35740|text=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 <code>--sg-cmake-arg</code> and/or <code>--fg-cmake-arg</code> 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 <code>$(...)</code> command substitution.

Using the (half-deprecated) environment variables <tt>SG_CMAKEARGS</tt> and <tt>FG_CMAKEARGS</tt>, 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 <tt>download_and_compile.sh</tt>, 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 <tt>download_and_compile.sh</tt>, 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 <tt>download_and_compile.sh</tt> 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 <tt>download_and_compile.sh</tt> in the directory where it is run, such as <tt>run_fgfs.sh</tt> and <tt>run_fgfs_debug.sh</tt>: these scripts automatically set up the required environment variables according to your build settings before firing the desired program (e.g., <tt>fgfs</tt>) with the arguments you provided.

Therefore, the simplest way to run a FlightGear program built by <tt>download_and_compile.sh</tt> is to launch the <tt>run_fgfs.sh</tt> script that <tt>download_and_compile.sh</tt> created in the directory from which it was run, for example:
$ cd ~/flightgear/dnc-managed
$ ./run_fgfs.sh --launcher

{{Note|<code>./run_fgfs.sh --launcher</code> starts FlightGear with its built-in launcher. If you just do <code>./run_fgfs.sh</code>, 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, [https://en.wikipedia.org/wiki/Paro_Airport 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 <tt>download_and_compile.sh</tt> to maintain several directory trees such as the tree starting at <tt>~/flightgear/dnc-managed</tt> in [[#getting-started-with-download-and-compile-sh|Getting started with <tt>download_and_compile.sh</tt>]] (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 <tt>download_and_compile.sh</tt> 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 <tt>~/flightgear/dnc-managed/install/flightgear/fgdata</tt>. 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 <tt>~/flightgear/dnc-managed/install/flightgear/fgdata</tt>.

{{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 [[Avoiding multiple downloads of FGData on Linux|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|Getting started with <tt>download_and_compile.sh</tt>]].}}

If you wish to get other programs (precisely: download, build and install them), you need to launch <tt>download_and_compile.sh</tt> with the desired component names as arguments. For instance:
$ cd ~/flightgear/dnc-managed
$ download_and_compile.sh SIMGEAR FGFS DATA OSG

See [[#list-of-available-components|above]] for the list of available components.

=== TerraGear ===

Run <tt>download_and_compile.sh</tt> 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 <tt>~/flightgear/dnc-managed</tt>:
* <tt>run_genapts850.sh</tt>
* <tt>run_ogr-decode.sh</tt>
* <tt>run_tg-construct.sh</tt>
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 <tt>download_and_compile.sh</tt> with the TERRAGEARGUI component:
$ cd ~/flightgear/dnc-managed
$ download_and_compile.sh TERRAGEARGUI
This will create a <tt>run_terrageargui.sh</tt> script in <tt>~/flightgear/dnc-managed</tt>, and also a default configuration file <tt>~/.config/TerraGear/TerraGearGUI.conf</tt>, 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 <tt>download_and_compile.sh</tt> to take care of the FGFS component. You can launch the standalone FGCom program by using the <tt>run_fgcom.sh</tt> script:
$ cd ~/flightgear/dnc-managed
$ ./run_fgcom.sh

=== FGRun ===

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

[[File:fgrun-page2.jpg|thumb|right]]
Before FlightGear had its built-in launcher (the one you get with <code>run_fgfs.sh --launcher</code>), many users found comfortable having FlightGear launched by the graphical utility [[Fgrun|FGRun]]. This program is built and installed when <tt>download_and_compile.sh</tt> is run with the FGRUN component. You then have to launch the <tt>run_fgrun.sh</tt> command, for example:
$ cd ~/flightgear/dnc-managed
$ ./run_fgrun.sh

FGRun will save its settings in <tt>~/.fltk/flightgear.org/fgrun.prefs</tt>. 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 <code>run_fgfs.sh --launcher</code>) or [[FFGo]].}}

[[File:Fgo01.jpg|thumb|left]]
FGo! is a graphical utility written in [[python]]. It is downloaded and installed when <tt>download_and_compile.sh</tt> is run with the FGO component. You then have to launch the <tt>run_fgo.sh</tt> 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 <tt>fgfs</tt> 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:
# 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.
# 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.
# 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|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 <tt>download_and_compile.sh</tt> 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 <tt>download_and_compile.sh</tt> script to clean OpenRTI with <code>rm -f CMakeCache.txt && rm -rf CMakeFiles/</code>, or just restart the build in a clean environment. Assuming you are in the base directory from which you ran <tt>download_and_compile.sh</tt>, you can run <code>download_and_compile.sh --cleanup</code> (see [[#Cleaning built and installed files|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 {{forum link|t=26244|text=this thread}} for more details. Note that <tt>download_and_compile.sh</tt> didn't have the <code>--cleanup</code> option at that time!

== Options ==

=== Release selection ===

* Build the latest stable release: <code>-s</code>
* Build the latest Long Term Stable release: <code>--lts</code>
* Build the previous Long Term Stable release: <code>--old-lts</code>

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

If you pass none of <code>-s</code>, <code>--lts</code> and <code>--old-lts</code> in a <tt>download_and_compile.sh</tt> 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, <tt>download_and_compile.sh</tt> 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 <code>--non-interactive</code> option in order to suppress these prompts (technically, this causes the default answer to be automatically used).

=== Cleaning built and installed files ===

Option <code>--cleanup</code> causes <tt>download_and_compile.sh</tt> 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 <code>--cleanup</code> 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 <code>-j x</code> to <tt>download_and_compile.sh</tt> (where ''x'' is the number of your CPU cores you wish to assign to the job) will considerably speed up the compilation steps. Passing <code>-j$(nproc)</code> is a convenient way to automatically use all available cores.

=== Advanced options ===

* Build a release version: <code>-b Release</code>
* Build a version that should run as fast as a release build, yet has debug information that can be used to post backtraces: <code>-b RelWithDebInfo</code> (this is the default)
* Build a full debug version for very complete bug reporting: <code>-b Debug</code>
* Skip download of distro packages (i.e., by default: <tt>apt-get install ...</tt>): <code>-p n</code>
* Skip retrieving of component downloads and updates (which typically use Git or wget): <code>-d n</code>
* Skip the configure step (like running [https://cmake.org/ CMake] or [https://www.gnu.org/software/autoconf/ autoconf]'s <tt>./configure</tt>): <code>-r n</code>
* Skip compilation of programs: <code>-c n</code>
* Build with compositor: <code>--compositor</code>
* Force the use of a particular branch for a given component: <code>--component-branch ''COMPONENT=BRANCH''</code> (e.g., <code>--component-branch OSG=OpenSceneGraph-3.6</code>, <code>--component-branch FGFS=next</code>, etc.—but remember that components FGFS, SIMGEAR and DATA must ''always'' be in sync). See [[#Component-specific settings|Component-specific settings]] for details.
* Override the repository from which a given component is initially fetched: <code>--override-repo ''COMPONENT''=''SITE'':''ADDRESS''</code> (see [[#Component-specific settings|Component-specific settings]]).
* Generate build.ninja files and build using Ninja: <code>-G Ninja</code>
* Run CMake in verbose mode: <code>--verbose</code> (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 <code>-rn</code> option may be necessary, though (this is the case in particular if you added or removed C++ files).

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

Export in environment:
export CMAKE_CXX_COMPILER_LAUNCHER=ccache

Or when running <code>download_and_compile.sh</code> 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 <tt>download_and_compile.sh</tt>):
$ sed 's|\./fgfs|optirun ./fgfs|' run_fgfs.sh > run_fgfs_optirun.sh && chmod +x run_fgfs_optirun.sh
Now you can run FlightGear with <code>./run_fgfs_optirun.sh</code>.

The same can be done for the [[FlightGear_Launch_Control|FGRun]] launcher:
$ sed 's|\./fgrun|optirun ./fgrun|' run_fgrun.sh > run_fgrun_optirun.sh && chmod +x run_fgrun_optirun.sh

== See also ==

* {{fgmeta source
| path = compile-scripts
| text = Other FlightGear build scripts
}} present in [[FGMeta]]
* {{fgmeta source
| path = fg-from-scratch
| simplepath = true
}}
* [http://geoffmclane.com/fg/fgfs-052.htm Another script] for building FlightGear and all its dependencies in an automated fashion. The page seems a bit oldish, though (as of 2019).

== References ==
<references/>

[[Category:Building from source]]

[[fr:Script de compilation sous Linux Debian/Ubuntu]]
[[nl:Compileren met een Script op Linux Debian/Ubuntu]]

Howto:Syntax highlighting for Nasal

2024-12-23T20:45:29Z

Jebba: /* Vim */ setup

There's '''[[Nasal]] syntax-highlighting''' support available for some editors, which is a big advantage, as it makes Nasal coding much easier.

Syntax highlighting can often point to syntax errors and so reduce the number of tedious time-consuming and unproductive [[FlightGear]] runs. It can also be a sort of "guide" to the language, highlighting functions or keywords that are builtin, so you can quickly check if it is "type" or "typeof" by typing each. In addition makes understanding other people's code easier, since you have all of the parts visually separated out, like loops, strings, constants, and builtin functions.

== Atom ==
Script is available from [https://github.com/www2000/atom-language-nasal Github] and can also be found in the [https://atom.io/packages/language-nasal Atom's packages repository].

Manual installation:

# Download the latest release from https://github.com/www2000/atom-language-nasal
# Unpack the tar.bz2
# Copy/move the language-nasal package to ~/.atom/packages

For installation from atom's packages repository:

# Open Atom
# Go to Preferences Edit -> Preferences or {{key press|Ctrl|+}},
# Click on packages and search for nasal
# Click install for Language Nasal

== Emacs ==
[[File:Emacs-nasal-syntax-highlighting.png|400px|thumb|Nasal syntax highlighting in GNU Emacs]]

There is an Emacs major mode for Nasal available in SimGear, that is based on Andy Ross' [https://github.com/andyross/nasal/blob/master/misc/nasal-mode.el original version]. In order to use it, you can copy the {{simgear source
| path = simgear/nasal/misc/nasal-mode.el
| text = nasal-mode.el
}} file where you have the rest of your manually installed packages and add the following line to your [https://www.gnu.org/software/emacs/manual/html_node/emacs/Init-File.html Emacs initialization file]:
<nowiki>(require 'nasal-mode)</nowiki>

In case you don't already have a directory to place your manually installed packages, put the file for instance in ''~/.emacs.d/manual-installs/'' (first create this directory if necessary) and insert the following in your Emacs initialization file before the above ''require'' line:
<nowiki>;; Tell Emacs it can load ELisp files from there
(add-to-list 'load-path "~/.emacs.d/manual-installs")</nowiki>

Once this is done, restart Emacs, check that no error is reported and open a .nas file.

Optional step: in order to speed up loading of nasal-mode.el, you can open it and choose ''Byte-compile this file'' from the ''Emacs-Lisp'' menu (or equivalently, run M-x byte-compile-file).

{{Tip|In case you have a clone of the {{simgear source
| text = SimGear repository
}} on your hard drive, you may create a symbolic link from ~/.emacs.d/manual-installs/nasal-mode.el to the file inside that repository; this way, you'll get automatic updates of nasal-mode.el when your SimGear repository is updated (Emacs will ignore the .elc file resulting from byte compilation if the corresponding .el file is more recent).}}

The '''true''' and '''false''' keywords introduced in January 2023 are already supported.<ref>https://forum.flightgear.org/viewtopic.php?f=30&t=41115&p=409029#p409029</ref>

== Geany ==

A syntax highlighting solution for [https://www.geany.org/ Geany], a lean text editor/IDE is available from [https://forum.flightgear.org/viewtopic.php?f=30&t=36838#p360677 this thread] in the FlightGear forum.

== gedit ==
[[File:Philosopher's nasal highlighting in gEdit.jpeg|400px|thumb|Screen shot illustrating syntax highlighting in gedit]]

'''Philosopher''' on the FlightGear Forum has created syntax highlighting for gedit, a popular and simple text editor for Mac OS X, Linux, and Windows.


To install, copy the ''nasal.lang'' file  from the first post of the forum topic {{forum link|p=164133}} and:

* If you use Mac, move it into your ''Applications/gedit/Contents/Resources/share/gtksourceview-X.0/language specs'' folder.
* For Linux, move it into your ''/usr/share/gtksourceview-X.0/language-specs'' folder.

In the same post given above, there are instructions for how to edit ''xml.lang'' (in the same directory) to add the embedded XML content support (with this minor edit, Nasal highlighting will be used inside of certain tags, instead of plain text).

For "snippets" support, nasal.xml from the above post has to be moved into ''/usr/share/gedit/plugins/snippets/'' folder or installed using the "import" feature. See this image for more details:

[[:File:Install nasal snippets in gedit.png|how to import Nasal snippets]].
{{-}}

== jEdit ==
There's a syntax highlighting mode for jEdit, programmer's text editor

Included are some of Nasal's internal functions and those functions currently implemented in NasalSys.cxx
To use, add the content of the catalog inside your own catalog (do NOT overwrite the file) and nasal.xml in /home/USER/.jedit/modes

Restart jEdit and you can use it. Current extension is .nas, you can add your own extension and functions.
This mode is heavily based on the Javascript mode.

Get it here: https://sourceforge.net/projects/fgscheduleview/files/jedit/catalog.zip/download

== KDE Editors ==
There's a highlighting definition for nasal available at '''opendesktop.org''' (https://www.opendesktop.org/p/1187022/)

Download the file and copy it into:
:~/.kde4/share/apps/katepart/syntax/ (for KDE4)
:or
:~/.local/share/katepart5/syntax/ (for KF5 pre 5.29)
:or
:~/.local/share/org.kde.syntax-highlighting/syntax/ (for current KF5 versions)

(you can create the folders if they don't exist yet).

Note that the syntax highlighting in KDE doesn't set colors, it just identifies structural elements, colors are defined by the '''schemas''' used by each editor, thus you get consistent highlighting between different languages.

The highlighting file should work with all editors based on the katepart: KWrite, Kate, and the editor component of KDevelop.

== Notepad++ ==
[[File:Highlight parse.png|400px|thumb|Screenshot of Nasal support for Notepad++]]
Provides comprehensive syntax highlighting and a function list parser with support for hierarchical display of both inline and out-of-body class member functions.
* [http://github.com/Slaiyer/nasal-npp <s>GitHub repository for download and instructions</s>]

For Windows 10 and Windows 11 you can just follow these simplified instructions.

Download the file userDefineLang.xml from https://github.com/slaiyer/nasal-npp.git and rename it to Nasal.xml.

The other files are no longer necessary.

Copy Nasal.xml to the directory /home/users/username/Appdata/roaming/Notepad++/userDefineLangs.

Close Notepad++.

Open a nasal file with Notepad++.

If the file is not highlighted (as in the image on the right) use the Language menu from the toolbar and select Nasal.

'''Alternative (syntax highlighting only):'''
* [http://dl.dropbox.com/u/1463693/nasal.xml Download here]
** [http://superuser.com/questions/62474/notepad-custom-syntax-highlighting-setting-where-to-look-for-it Instructions are here]
{{-}}

== Sublime Text 2 ==
[[File:Sublime Text 2 syntax highlighting.png|400px|thumb|Sublime Text 2 syntax highlighting]]

Scripts and installation instructions are here: https://github.com/freevryheid/nasal
{{-}}

== Sublime Text 4 ==
Scripts and installation instructions are here: https://github.com/NikolaiVChr/sublime-nasal
{{-}}

== Vim ==
[[File:Vim-nasal-syntax-highlighting.png|400px|thumb|Screen shot illustrating syntax highlighting in Vim]]

One such editor is the free vim or its GUI variant gvim.

It's not for everyone but it's free, and testing it doesn't hurt: http://www.vim.org/.

The syntax definition file comes with the FlightGear code ({{flightgear file|scripts/syntax/nasal.vim}}). Highlighting works even for Nasal embedded in XML files (type ":set ft=nasal", where ft stands for file-type)

Here's an example, which demonstrates a short code segment with three syntax errors as well as the highlighting of a matching pair of parentheses (yellow) and trailing spaces (blue x). (The leading blue dots aren't on by default. They help to spot tab crimes.)
{{-}}

=== Vim Setup ===
Nasal highlighting in Vim can be set up thusly:

mkdir -p ~/.vim/syntax

Download <code>nasal.vim</code> such as from here:
https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/scripts/syntax/nasal.vim?format=raw

Or get <code>nasal.vim</code> from your flightgear/flightgear git repo: <code>scripts/syntax/nasal.vim</code>.

Copy that file to here:

~/.vim/syntax/nasal.vim

Then create a file named <code>~/.vim/filetype.vim</code> and add this line:

au BufRead,BufNewFile *.nas set filetype=nasal

== Visual Studio Code ==
[[File:Vscode-sintaxhighlight.jpg|thumb|Screen shot illustrating syntax highlighting in VSCode]]

[https://code.visualstudio.com Visual Studio Code] is a source-code editor developed by Microsoft for Windows, Linux and macOS. Its open source and free.

The nasal extension is available from [https://github.com/RenanMsV/nasal-vscode Github] and can also be found in the [https://marketplace.visualstudio.com/items?itemName=Renan-MsV.nasal-lang VSCode's marketplace].
It supports basic syntax highlighting and snippets to improve development speed.

For installation from the marketplace:

# Open VSCode
# Go to File -> Preferences -> Extensions or {{key press|Ctrl|Shift|X}},
# Search for nasal
# Click install for Nasal Language (FlightGear)

Manual installation:

# Download the latest release from the repository, it should be a .vsix file.
# Install the extension manually by doing the command 'code --install-extension path_to_extension.vsix'

{{-}}

== TextMate==
[[File:Nasal syntax highlighting in TextMate.png|thumb|Screen shot illustrating syntax highlighting in TextMate]]
[https://macromates.com/ TextMate] is a general-purpose GUI text editor for macOS created by Allan Odgaard. It is open source and free to use.

There is a TextMate Bundle for Nasal available on [https://github.com/BobDotCom/Nasal.tmbundle GitHub] which can be [https://macromates.com/manual/en/bundles#installing_a_bundle installed in TextMate] for basic syntax highlighting.

{{-}}

==IntelliJ Family Editors (JetBrains)==
[[File:Nasal syntax highlighting in PyCharm.png|thumb|Screenshot illustrating syntax highlighting in PyCharm]]
[https://www.jetbrains.com/idea/ IntelliJ IDEA] is an integrated development environment written in Java for developing computer software written in Java, Kotlin, Groovy, and other JVM-based languages. It is developed by JetBrains and is available as an Apache 2 Licensed community edition, and in a proprietary commercial edition.

Although there is not a native IntelliJ plugin for Nasal, IntelliJ supports [https://www.jetbrains.com/help/idea/textmate-bundles.html installing TextMate bundles] for syntax highlighting, so the [https://github.com/BobDotCom/Nasal.tmbundle Nasal TextMate Bundle] can be used. Installation instructions are available [https://www.jetbrains.com/help/webstorm/tutorial-using-textmate-bundles.html here].

There are many [https://www.jetbrains.com/products/ JetBrains products] that are based on IntelliJ such as [https://www.jetbrains.com/pycharm/ PyCharm] (Python) and [https://www.jetbrains.com/webstorm/ WebStorm] (Javascript). These IDEs can also be used with nasal syntax highlighting, in the same way as above.

{{-}}

==Other editors==
Nasal being syntactically very close to other programming languages like C, Php or JavaScript, you can get some usable highlighting even without real Nasal support:

* TextMate {{forum link|hilit=syntax+nasal|p=127828}}
*SciTe {{forum link|hilit=syntax+nasal|p=94521}}

==FlightGear Wiki==
{{Note|As of 02/2016, we do not currently have a dedicated Nasal module available [http://wiki.flightgear.org/FlightGear_wiki:Village_pump/Archive_2016#Nasal_Syntaxhighlighting]}}
{{main article|Help:Formatting#Syntax highlighting}}

Using the <syntaxhighight> tag with a lang="nasal" attribute, we can have highlighting right here on the wiki. Use enclose="div" to wrap the text, if it happens to be particularly wide.

<nowiki><syntaxhighlight lang="nasal">
# hello.nas
print('Hello World!');
</syntaxhighlight></nowiki>

Which renders into:
<syntaxhighlight lang="nasal">
# hello.nas
print('Hello World!');
</syntaxhighlight>

==Syntax highlighting test==
Just a collection of keywords, etc. to test whether highlighting works (you can copy this to test your own highlighting):
<syntaxhighlight lang="nasal">
# this is a comment
# operators (if applicable):
!a ? a+b - c/d*e : f~g; expr1 and expr2 or expr3;
# Builtin functions, strings
print('Hello World!');
die("We have an error, Houston!", arg[0]);
cmdarg().getNode("setting").getValue();
streq(typeof(id(keys(hash))),10);
# Loopoids
foreach (var a; ["haha", {command:"NASAL!"}, me]) {
if(0) break;
elsif(1) continue;
else return;
while(1) sprintf("%s%s\n%s=%f", "Spam", "spam", "spam", 0e-0);
for (var i=0; i < 0.00; i += 0x0) printf("%d", int(i));
forindex(var o; a) (func {
var o = o;
setlistener("/", func print(o), 1, 2);
})();
}
# String escaping stress tests:
'\a\b\c\"\\\?' # none of these
"\e\?\'\f\a" # none of these
'\'' # this one
"\"\r\n\t\\\t" # and all of these
# And optionally string formatting:
"%s%%s%.0f%8d" # the second "s" shouldn't be highlighted, otherwise everything else
# Syntax error!:
%$@&^|\`
</syntaxhighlight>

==Related content==
*{{forum url|p=164155}}
*{{forum url|t=12495}}
*{{forum url|t=15972}}
*{{forum url|t=9812}}

[[Category:Nasal howto]]

<references />

Scripted Compilation on Linux Debian/Ubuntu

2024-12-23T19:43:14Z

Jebba: /* Options */ Ccache

<tt>download_and_compile.sh</tt> 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<ref name="just-one-command">Due to technical problems on the [https://sourceforge.net/ SourceForge] side, this is currently only true once you have an [[FGData]] clone. See [[User:Rominet|here]] for details.</ref> for both 32-bit and 64-bit [https://www.debian.org/ Debian]-based systems. Pre-existing versions (if any) of the software installed by <tt>download_and_compile.sh</tt> 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, <tt>download_and_compile.sh</tt> installs packages with <tt>apt-get</tt>. For this reason, it is primarily useful on Debian-based distributions. However, if one disables package installation (using <code>-pn</code> or <code>--sudo=echo</code>) 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 [https://www.openbsd.org/ OpenBSD].

For hints on using <tt>rpm</tt>-based distributions such as Redhat, Fedora and CentOS, please see [[CentOS]]. Please also see [[Superbuild]].

== Introduction ==

<tt>download_and_compile.sh</tt> is a [https://www.gnu.org/software/bash/ Bash] script written for [https://www.debian.org/ Debian]-derived distributions ([https://www.ubuntu.com/ Ubuntu], [https://devuan.org/ Devuan], [https://www.linuxmint.com/ Linux Mint], etc.). Its purpose is to automatically install dependencies using the package manager, then build and install FlightGear-related programs.

By default, <tt>download_and_compile.sh</tt> installs most dependencies with <tt>apt-get</tt> run under <tt>sudo</tt>.<ref name="disabling-installation-of-dependencies-via-package-manager">If you think you already have the dependencies, this installation can be disabled either by using option <code>-pn</code> or by passing option <code>--sudo=echo</code> (the latter results in printing the <tt>apt-get</tt> command line without running it).</ref> Other dependencies, either because they aren't available in the standard APT repositories, or because of non-option arguments passed to <tt>download_and_compile.sh</tt>, 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).

<tt>download_and_compile.sh</tt> works in the directory it is run from: apart from dependencies installed via the package manager, all programs built by <tt>download_and_compile.sh</tt> are installed under the <tt>install</tt> subdirectory of the directory from which the script was run. In other words, installation of programs by <tt>download_and_compile.sh</tt> 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 <tt>download_and_compile.sh</tt>; as far as it is concerned, such directory trees are completely independent from each other. For instance, if you run <tt>download_and_compile.sh</tt> in <tt>dir1</tt> and <tt>dir2</tt>, the programs installed under <tt>dir1</tt> won't “see” those installed under <tt>dir2</tt>, and vice versa.

Apart from its main purpose, <tt>download_and_compile.sh</tt> can be used to find hopefully up-to-date build-dependency information for FlightGear and related software. You would do so by inspecting [https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/download_and_compile.sh the script] at the point where it installs packages.<ref name="note-inspecting-download-and-compile-sh-to-gather-build-dependency-information">Look for strings such as <tt>zlib1g-dev</tt>, <tt>libglew-dev</tt> or <tt>qt5-default</tt>.</ref>

== Prerequisites ==

Before embarking on building your own FlightGear binaries, you need to install a few tools that <tt>download_and_compile.sh</tt> uses to retrieve and compile source code. These tools are found in the following packages on [https://www.debian.org/ 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 <tt>download_and_compile.sh</tt> 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 [https://en.wikipedia.org/wiki/Gibibyte 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 <code>-j8</code> 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 <tt>download_and_compile.sh</tt> {{fgmeta source
| path = download_and_compile.sh
| text = 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 <code>download_and_compile.sh --version</code> work as intended, it is recommended to get it as explained [[#getting-download-and-compile-sh-using-an-fgmeta-clone|below]].

In case you build stable versions of FlightGear using either of the <code>-s</code>, <code>--lts</code> and <code>--old-lts</code> options of <tt>download_and_compile.sh</tt>, remember to update the script before trying to build a new version of FlightGear (see [[#updating-download-and-compile-sh-using-an-fgmeta-clone|Updating <tt>download_and_compile.sh</tt>]] 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 <tt>download_and_compile.sh</tt> ==

=== 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 <code>-pn</code> or something similar to disable installation of packages from your distribution, you'll be asked for your <tt>sudo</tt> password during execution of the <tt>download_and_compile.sh</tt> command (<tt>sudo</tt> is used by <tt>download_and_compile.sh</tt> to run commands like <tt>apt-get</tt>). So, here is your quick recipe for getting <tt>download_and_compile.sh</tt> and using it to build FlightGear:
mkdir -p ~/flightgear/dnc-managed
cd ~/flightgear
<nowiki>git clone https://git.code.sf.net/p/flightgear/fgmeta</nowiki>
cd ~/flightgear/dnc-managed
~/flightgear/fgmeta/download_and_compile.sh -s -j$(nproc)
./run_fgfs.sh --launcher

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

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

In some cases, <tt>download_and_compile.sh</tt> 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 <code>--non-interactive</code> option to suppress them.

More detailed instructions are given below. The following sections also explain how to update <tt>download_and_compile.sh</tt> 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:
* <tt>~/flightgear/fgmeta</tt> will contain a clone of the [[FGMeta]] repository; therefore, <tt>download_and_compile.sh</tt> will reside in that directory;
* <tt>~/flightgear/dnc-managed</tt> will be the directory from which we run <tt>download_and_compile.sh</tt>. 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 <tt>download_and_compile.sh</tt> the “right way” ===

There are several ways to obtain [https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/download_and_compile.sh download_and_compile.sh]. The method described here makes it very easy to update the script and causes the command <code>download_and_compile.sh --version</code> to work as intended.

As explained in [[#getting-started-with-download-and-compile-sh-notations|Notations]], we want to clone the [[FGMeta]] repository in <tt>~/flightgear/fgmeta</tt> and work with its ''next'' branch. Let's go:
$ mkdir -p ~/flightgear
$ cd ~/flightgear
<nowiki>$ git clone -b next https://git.code.sf.net/p/flightgear/fgmeta</nowiki>
You now have a fresh FGMeta clone in <tt>~/flightgear/fgmeta</tt> and your brand new <tt>download_and_compile.sh</tt> script is located in that directory. You can already try it to see the available options:
<pre>$ ~/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

(...)</pre>

=== Updating <tt>download_and_compile.sh</tt> ===

Now that you have <tt>download_and_compile.sh</tt> from the [[FGMeta]] repository, it is very easy to update (this assumes you didn't modify anything yourself inside <tt>~/flightgear/fgmeta</tt>!):
$ cd ~/flightgear/fgmeta && git pull

If you want to keep updates as easy as we just showed, it is best not to modify <tt>download_and_compile.sh</tt> yourself. <tt>download_and_compile.sh</tt> has plenty of options that usually make it unnecessary to modify the script. Just run <code>download_and_compile.sh --help</code> 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 <tt>download_and_compile.sh</tt>, you are invited to skip to the next section.

If you really, ''really'' want to modify <tt>download_and_compile.sh</tt> 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 <code>git status</code>), 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 <tt>download_and_compile.sh</tt>. 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 <tt>download_and_compile.sh</tt> when showing commands to be run, but you should prepend it to <tt>download_and_compile.sh</tt> whenever you see a <tt>download_and_compile.sh</tt> command. For instance, if you used the same path as in [[#getting-started-with-download-and-compile-sh-notations|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 <tt>download_and_compile.sh</tt> commands from an arbitrary directory, in particular ''don't'' run them from <tt>~/flightgear/fgmeta</tt>. This is because '''most other <tt>download_and_compile.sh</tt> commands write to the current directory''' (<code>download_and_compile.sh --help</code> and <code>download_and_compile.sh --version</code> 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 [https://sourceforge.net/p/flightgear/mailman/message/36634426/ this message]), by adding the directory containing <tt>download_and_compile.sh</tt> to your <tt>PATH</tt> or by creating a symbolink link pointing to <tt>download_and_compile.sh</tt> in a directory that is part of your <tt>PATH</tt>. 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 <tt>PATH</tt>).

{{Note|The following commands should be run from an empty directory<ref name="dedicated-directory-won-t-stay-empty-forever">Well, empty before the first time; later, <tt>download_and_compile.sh</tt> is going to populate it with plenty of FlightGear files and subdirectories, of course.</ref> in a partition that has enough free space (see [[#disk-space-requirements-and-build-time | Disk space requirements and build time]]). As explained in [[#getting-started-with-download-and-compile-sh-notations|Notations]], we are going to choose the directory <tt>~/flightgear/dnc-managed</tt> for this purpose, in order to express that the whole directory tree is managed by <tt>download_and_compile.sh</tt>. 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 <tt>download_and_compile.sh</tt> 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, <tt>download_and_compile.sh</tt> may use <tt>sudo</tt>. In case you want to run some other program instead of <tt>sudo</tt>, this can be done with the <code>--sudo</code> option of <tt>download_and_compile.sh</tt>. For instance, in order to see the commands that would be run with sudo without actually running them, you can pass <code><nowiki>--sudo=echo</nowiki></code> to <tt>download_and_compile.sh</tt>. Like all other options, <code>--sudo</code> must be given ''before'' all arguments that are component names (such as <tt>SIMGEAR</tt>, <tt>FGFS</tt>, <tt>DATA</tt>, etc.).}}

The package manager used by <tt>download_and_compile.sh</tt> by default is <tt>apt-get</tt> (it won't be used if you pass <tt>download_and_compile.sh</tt> the <code>-pn</code> 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 <tt>aptitude</tt> as well as <tt>apt</tt>. If you want <tt>download_and_compile.sh</tt> to use <tt>aptitude</tt>, give it the option <code><nowiki>--package-manager=aptitude</nowiki></code> before any of the ''COMPONENT'' arguments.

All options of <tt>download_and_compile.sh</tt> 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 <tt>download_and_compile.sh</tt> will be stored. This is <tt>~/flightgear/dnc-managed</tt> if you followed the suggestions given in [[#getting-started-with-download-and-compile-sh-notations|Notations]], and should be empty before you run <tt>download_and_compile.sh</tt> for the first time. However, it is quite correct to start <tt>download_and_compile.sh</tt> from the same directory for subsequent runs, even when non-empty (otherwise, <tt>download_and_compile.sh</tt> 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 <code>-j$(nproc)</code> 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| Multicore acceleration]].

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

When you don't pass any non-option argument to <tt>download_and_compile.sh</tt> as done here, it takes care of the base components needed to run FlightGear in good conditions: <tt>SIMGEAR</tt>, <tt>FGFS</tt>, <tt>DATA</tt> and <tt>OSG</tt> (these are the component names used by <tt>download_and_compile.sh</tt>, i.e., the final arguments one can optionally give in a <tt>download_and_compile.sh</tt> command; in normal speech, they correspond to the {{simgear source
| text = SimGear
}}, {{flightgear source
| text = FlightGear
}} and {{fgdata source
| text = 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 <tt>run_fgfs.sh</tt> in the directory from which you ran <tt>download_and_compile.sh</tt> (i.e., <tt>~/flightgear/dnc-managed</tt> in the suggested setup). This will be your script to run FlightGear. For instance, in order to start the [[FlightGear Qt launcher|built-in launcher]], you can run the following commands:<ref name="no-need-to-change-to-dnc-managed-dir-before-starting-generated-scripts">We give these commands because they are easy to read, but the <code>cd</code> command is not needed if you use the correct path, as in <code>~/flightgear/dnc-managed/run_fgfs.sh --launcher</code>.</ref>
$ cd ~/flightgear/dnc-managed
$ ./run_fgfs.sh --launcher
(You may omit the <code>--launcher</code> 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 [https://sourceforge.net/p/flightgear/mailman/message/36634426/ this message] or use another launcher such as [[FFGo]]—but the [[FlightGear Qt launcher|FlightGear built-in launcher]] started with <code>run_fgfs.sh --launcher</code> is quite fine, be sure to try it first!

{{Note|If you ran <tt>download_and_compile.sh</tt> from <tt>~/flightgear/dnc-managed</tt> as proposed above, the full path of the <tt>~/flightgear/dnc-managed/install/flightgear/fgdata</tt> 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 <code>-s</code>, <code>--lts</code> and <code>--old-lts</code>, you need to pass the ''same option'' to the <tt>download_and_compile.sh</tt> command given below that will update your FlightGear installation. Otherwise, <tt>download_and_compile.sh</tt> 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 <code>--cleanup</code> option of <tt>download_and_compile.sh</tt> is heartily recommended.}}

Keeping the above note in mind, go to the directory from which you previously ran <tt>download_and_compile.sh</tt> (<tt>~/flightgear/dnc-managed</tt> in the [[#Notations|suggested setup]]). This is the folder which, if you did a complete run of <tt>download_and_compile.sh</tt> as shown in the previous section, contains the <tt>run_fgfs.sh</tt> script and a log file named <tt>compilation_log.txt</tt> that records what <tt>download_and_compile.sh</tt> did in its last run. If you wish to update, say, {{simgear source
| text = SimGear
}}, {{flightgear source
| text = FlightGear
}}, {{fgdata source
| text = FGData
}} and [[OpenSceneGraph|OSG]], simply execute this:
$ download_and_compile.sh -pn -j$(nproc) SIMGEAR FGFS DATA OSG
The <code>-j$(nproc)</code> 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| Multicore acceleration]].

We'll explain the <code>-pn</code> in a minute. <tt>SIMGEAR</tt>, <tt>FGFS</tt>, <tt>DATA</tt> and <tt>OSG</tt> are called ''components'' in <tt>download_and_compile.sh</tt> terminology. A component generally corresponds to a software repository, or something close. In fact, since <tt>SIMGEAR</tt>, <tt>FGFS</tt>, <tt>DATA</tt> and <tt>OSG</tt> 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 <code>-pn</code>. It is equivalent to <code>-p n</code> and means “don't install packages from my (Linux) distribution” (<code>y</code> means ''yes, please install'', <code>n</code> means ''no, don't install''). In case you forgot that, simply run:
$ download_and_compile.sh --help
What does it imply to pass <code>-pn</code>? This tells <tt>download_and_compile.sh</tt> to completely skip the step where it checks for needed packages from your distribution and installs them, by default using <tt>apt-get</tt>. It thus goes straight to the following steps:
* update each repository corresponding to one of the selected components (<tt>SIMGEAR</tt>, <tt>FGFS</tt>, <tt>DATA</tt> and <tt>OSG</tt> in our example);
* compile each selected component that requires compilation;
* install each selected component in the appropriate place (under <tt>~/flightgear/dnc-managed</tt> according to our [[#getting-started-with-download-and-compile-sh-notations|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 <code>-pn</code> to <tt>download_and_compile.sh</tt>, you forbid it to install these dependencies for you. So, you can also very well update without passing the <code>-pn</code> option, it will simply take a little longer (the time to check if all dependencies of the selected components are available with <tt>APT</tt>). In fact, this is '''what you should do if the previous <tt>download_and_compile.sh</tt> run failed:''' first update <tt>download_and_compile.sh</tt> (see [[#getting-download-and-compile-sh-using-an-fgmeta-clone|above]]) then run it ''without'' <code>-pn</code><ref name="passing-no-pn-option-equals-passing-py">Which is the same as passing <code>-py</code>.</ref> 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 <code>download_and_compile.sh --cleanup</code> to restart the build from a clean state is probably a good idea (see [[#Cleaning built and installed files|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 <tt>download_and_compile.sh</tt> (see [[#getting-download-and-compile-sh-using-an-fgmeta-clone|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 <tt>SIMGEAR FGFS DATA OSG</tt> if you don't specify any.

=== Examining the history of <tt>download_and_compile.sh</tt> ===

Looking at the latest commits that affected <tt>download_and_compile.sh</tt> is quite easy with your FGMeta clone:
$ cd ~/flightgear/fgmeta
$ git log -- download_and_compile.sh
(then quit by typing <tt>q</tt>, assuming your <tt>$GIT_PAGER</tt> is <tt>less</tt>) 

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 [https://sourceforge.net/ SourceForge] infrastructure (namely, <code>git clone</code> from SourceForge doesn't work for the big FGData repository using https). Current versions of <tt>download_and_compile.sh</tt> avoid the problem by proposing the user to automatically clone FGData from its [https://gitlab.com/flightgear/fgdata 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 [https://sourceforge.net/ SourceForge] using the SSH protocol, you'll need an account on that site. If you don't already have one, go to the [https://sourceforge.net/user/registration 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 [[#getting-started-with-download-and-compile-sh-notations|Notations]], we assume that your Unix user name (login) is <tt>toto</tt>. Don't confuse the <tt>sudo</tt> password prompt (where you need to enter <tt>toto</tt>'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, <tt>download_and_compile.sh</tt> may use <tt>sudo</tt>. In case you want to run some other program instead of <tt>sudo</tt>, this can be done with the <code>--sudo</code> option of <tt>download_and_compile.sh</tt>. For instance, in order to see the commands that would be run with sudo without actually running them, you can pass <code><nowiki>--sudo=echo</nowiki></code> to <tt>download_and_compile.sh</tt>. Like all other options, <code>--sudo</code> must be given ''before'' all arguments that are component names (such as <tt>SIMGEAR</tt>, <tt>FGFS</tt>, <tt>DATA</tt>, 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 <code>-s</code> or <code>--lts</code> to all <tt>download_and_compile.sh</tt> commands given below (or <code>--old-lts</code> for the previous LTS release). You may add the chosen option right after the <tt>download_and_compile.sh</tt> command name (in any case, the option should come before non-option arguments such as SIMGEAR, FGFS, DATA, etc.). See [[#Release selection|Release selection]] for more explanations on options <code>-s</code>, <code>--lts</code> and <code>--old-lts</code>.}}

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

Ready? Let's go!
<pre>$ 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.
</pre>

The above messages are perfectly normal but deserve a little explanation. Here, <tt>ssh</tt> asked us to confirm that the fingerprint sent by the remote host is that of the real <tt>git.code.sf.net</tt>, as opposed to that of some malicious server ''pretending'' to be <tt>git.code.sf.net</tt>. This confirmation only has to be done once, after which it is remembered thanks to <tt>~/.ssh/known_hosts</tt>. You should visit the [https://sourceforge.net/p/forge/documentation/SSH%20Key%20Fingerprints/#fingerprint-listing 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 <tt>git.code.sf.net</tt>, or some matching pattern such as <tt>*.code.sf.net</tt>.

If the fingerprint that is printed on your terminal is not listed on that page, answer <tt>no</tt> 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 <tt>ssh</tt> that contains the fingerprint sent to you by the remote host which pretends to be <tt>git.code.sf.net</tt>. 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 <tt>yes</tt> 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 <tt>git.code.sf.net</tt> server and confirm it to <tt>ssh</tt>. Because of this delay, <tt>git.code.sf.net</tt> hung up on us and closed the connection. This is absolutely ''not a problem:'' we can just rerun the <tt>download_and_compile.sh</tt> command with the same arguments as the first time. Since we answered <tt>yes</tt> to the ''Are you sure you want to continue connecting (yes/no)?'' prompt, the fingerprint of <tt>git.code.sf.net</tt>'s key has been stored in <tt>~/.ssh/known_hosts</tt>, therefore we won't get this prompt anymore. But if some server claiming to be <tt>git.code.sf.net</tt> presents a host key that has a different fingerprint in the future, <tt>ssh</tt> will print a big fat warning that the server may belong to an attacker trying to impersonate <tt>git.code.sf.net</tt>. 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 <tt>download_and_compile.sh</tt> command with the same arguments:
<pre>$ 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:</pre>
As explained above, the preceding prompt is for your SourceForge password (which you could guess from the <code><nowiki>git clone ssh://SFusername@git.code.sf.net/p/flightgear/fgdata</nowiki></code> command).
<pre>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:</pre>
(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 <tt>download_and_compile.sh</tt> wants to run <code>git pull --rebase</code> in the repository (admittedly, it's a bit dumb after a <tt>clone</tt> operation—please forgive us). In case you were not monitoring the <tt>clone</tt> operation, you probably saw the password prompt way after <tt>git.code.sf.net</tt> got bored waiting for you and closed our second connection:
<pre>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.</pre>
(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:
<pre>$ 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.
</pre>
There we are! You now have a clean, up-to-date [[FGData]] clone in <tt>~/flightgear/dnc-managed/install/flightgear/fgdata</tt> (remember: <tt>~/flightgear/dnc-managed</tt> is the directory from which you ran <tt>download_and_compile.sh</tt>). Note this place: the full path of the <tt>~/flightgear/dnc-managed/install/flightgear/fgdata</tt> directory is your [[$FG_ROOT]].

Now, change the protocol to use for future updates of your FGData clone:<ref name="changing-the-protocol-for-a-git-remote-manual-method">Another way would be to manually change the relevant line starting with <code>url = <nowiki>ssh://SFusername@</nowiki></code> for the <code>origin</code> remote in the <tt>.git/config</tt> file that lives inside your repository clone (i.e., <tt>~/flightgear/dnc-managed/install/flightgear/fgdata/.git/config</tt> in our example).</ref>
(cd install/flightgear/fgdata && \
git remote set-url origin <nowiki>https://git.code.sf.net/p/flightgear/fgdata</nowiki>)
(you can check at any time the protocol(s) in use with the command <code>git remote -v</code> run inside a Git repository—in this case, inside the folder <tt>install/flightgear/fgdata</tt>). As a consequence of this change, all future updates of your FGData clone will use the <tt>https</tt> 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 (<tt>~/flightgear/dnc-managed</tt> in our example):
$ download_and_compile.sh -j$(nproc)
The <code>-j$(nproc)</code> 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| Multicore acceleration]].

Assuming the compilation was successful, you can now start the [[FlightGear Qt launcher|FlightGear built-in launcher]] using for instance:
$ ./run_fgfs.sh --launcher
See [[#Building FlightGear|Building FlightGear]] for more details.

== List of available components ==

The <tt>download_and_compile.sh</tt> 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 [https://cmake.org/ 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|FGRun]] FlightGear launcher)
* FGX (for the [[FGX|FGx]] FlightGear launcher<ref name="note-on-the-status-of-FGx-support-in-download-and-compile-sh">Support for FGx in <tt>download_and_compile.sh</tt> would probably benefit from a code review.</ref>)
* OPENRADAR (for the [[OpenRadar]] air traffic control simulation program)
* OPENRTI (for [[FlightGear HLA support (High Level Architecture)#OpenRTI | OpenRTI]]<ref name="note-on-the-status-of-OpenRTI-support-in-FG">Note that OpenRTI is just an optional dependency for [[FlightGear high-level architecture support | HLA support]]. For the time being, you should be just fine building without it. Eventually, the idea is for HLA to replace the existing MP system and even increasingly distribute the FlightGear architecture such that more and more components can be more easily run in separate threads or even separate processes, possibly even on different machines. So this is going to be an important feature for professional users, using several computers and screens to create a comprehensive and immersive simulation environment.

At the moment, it is probably safe to say that HLA is only of interest to developers and people willing to play with experimental features.</ref>)
* 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 [http://www.zlib.net/ zlib] compression library)

Each of the items listed above is a ''component'' in <tt>download_and_compile.sh</tt> 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 <tt>download_and_compile.sh</tt> can always be obtained by running <code>download_and_compile.sh --help</code>.}}

What is the point of knowing this? Because you may pass component names to <tt>download_and_compile.sh</tt> in order to tell it what you want to download, build and install. By default, only the components [[SimGear|SIMGEAR]], [[FlightGear|FGFS]], [[FGData|DATA]] and [[OpenSceneGraph|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, <tt>download_and_compile.sh</tt> 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 <code>-s</code>) or the latest Long Term Stable release (option <code>--lts</code>) 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 <code>--lts</code>; for instance, in July 2020, <code>--lts</code> didn't build with OpenSceneGraph 3.6, but simply passing the OSG component on the <tt>download_and_compile.sh</tt> command solved the problem, because at that time, option <code>--lts</code> 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_lists|mailing list]] in case a problem popped up<ref name="what-to-provide-when-asking-for-help">Don't forget in this case to precisely tell what you did and include the <tt>compilation_log.txt</tt> file written by <tt>download_and_compile.sh</tt>.</ref> 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 <code>-s</code>) or the latest Long Term Stable release (option <code>--lts</code>). In case you want something even older, the previous LTS release can be selected with option <code>--old-lts</code>.}}

== 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|Getting started with <tt>download_and_compile.sh</tt>]].}}

=== Selecting the components to build ===

By default, <tt>download_and_compile.sh</tt> downloads or updates, then compiles, [[SimGear]], FlightGear, [[FGData]] and [[OpenSceneGraph|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 <tt>download_and_compile.sh</tt> 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 [https://cmake.org/ CMake] in <tt>download_and_compile.sh</tt>'s terminology.

A [[#list-of-available-components|list of available components]] is provided on this page, but the fully up-to-date list can always be obtained by running <code>download_and_compile.sh --help</code>.

=== Choosing between stable and development versions ===

By default, <tt>download_and_compile.sh</tt> 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 <code>-s</code>, <code>--lts</code> and <code>--old-lts</code> 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]], <code>-s</code> uses the most recent stable release branch of the corresponding Git repository, <code>--lts</code> uses the most recent Long Term Stable release (LTS) and <code>--old-lts</code> uses the previous LTS release.
* For other components, a known-stable version is selected by <tt>download_and_compile.sh</tt>, which may be influenced by the use of <code>-s</code>, <code>--lts</code> or <code>--old-lts</code>.

So, as far as the SIMGEAR, FGFS and DATA components are concerned, you can:
* build the latest stable release (<code>-s</code>);
* build the latest Long Term Stable release (<code>--lts</code>);
* build the previous Long Term Stable release (<code>--old-lts</code>);
* build the current development version (bleeding edge), which lives in the {{flightgear source
| branch = next
| text = next
}} branch of the FlightGear repository.
The use of <code>-s</code>, <code>--lts</code> or <code>--old-lts</code> also influences the version of other components you may have selected (this can be overridden using <code>--component-branch</code> for advanced users—see [[#Component-specific settings|Component-specific settings]]).

{{Note|In a given folder where <tt>download_and_compile.sh</tt> is run, you should normally either always use the <code>-s</code> option, or always use <code>--lts</code>, or always use <code>--old-lts</code>, 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 <code>--cleanup</code> option when doing the switch (see [[#Cleaning built and installed files|Cleaning built and installed files]] for information on this option). For instance:
* Build with <code>-s</code> as many times as you want.
* Want to try ''next''? Okay, then build once with <code>--cleanup</code> (no <code>-s</code> option anymore).
* You can then perform as many builds of ''next'' as you want; no need to use <code>--cleanup</code> unless something special went wrong.
* If you later decide to switch back to the stable release, build once with <code>-s</code> and <code>--cleanup</code>, then only with <code>-s</code> 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 <tt>download_and_compile.sh</tt>, use the <code>--lts</code> 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 [[#selecting-the-components-to-work-on | above]].)

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

==== Building the latest stable release of FlightGear ====

When executing <tt>download_and_compile.sh</tt>, use the <code>-s</code> option to build the latest stable release:
$ cd ~/flightgear/dnc-managed
$ download_and_compile.sh -s

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

==== Building the current FlightGear development version ====

When executing <tt>download_and_compile.sh</tt> 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 <tt>download_and_compile.sh</tt>, use the <code>--old-lts</code> 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 [[#selecting-the-components-to-work-on | above]].)

{{Note|If you decide to use the <code>--old-lts</code> option in a given directory tree, you should use it for all components in that directory tree (SIMGEAR, FGFS, DATA, etc.). Running <tt>download_and_compile.sh</tt> in a given directory with the <code>--old-lts</code> 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 <tt>fgfs-osg-36-2</tt> of the Git repository located at [https://gitlab.com/flightgear/openscenegraph.git https://gitlab.com/flightgear/openscenegraph.git] (this is actually the default in September 2024). Since the default protocol used when <tt>download_and_compile.sh</tt> clones a repository is [https://en.wikipedia.org/wiki/HTTPS 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 ====

<tt>download_and_compile.sh</tt> uses case-insensitive short names such as <tt>GitHub</tt>, <tt>SourceForge</tt> and <tt>gitlab.kitware.com</tt> 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 <code>download_and_compile.sh --help</code>, in particular in the <tt>--git-clone-site-params</tt> and <tt>--override-repo</tt> options we'll present below. These ''site'' keys are simply identifier strings; they are not used in the DNS queries.

==== The protocol ====

Current <tt>download_and_compile.sh</tt> (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 <tt>wget</tt> and are out-of-scope for this section.

The default protocol used by <tt>download_and_compile.sh</tt> when cloning a Git repository is [https://en.wikipedia.org/wiki/HTTPS HTTPS]. This can be overridden using the <tt>--git-clone-default-proto</tt> option. In other words, the default is <tt>--git-clone-default-proto=https</tt> (the protocol name is case-insensitive). Other possibilities for the protocol are <tt>git</tt> and <tt>ssh</tt>.

{{Warning|The <tt>git</tt> 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 <tt>ssh</tt> protocol as the argument of <tt>--git-clone-default-proto</tt> 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, <tt>~/.ssh/config</tt> can be used to automatically provide a site-dependent username). That is why <tt>download_and_compile.sh</tt> offers the <tt>--git-clone-site-params</tt> option.

==== Site-specific settings ====

Using
--git-clone-site-params ''SITE''=''PROTOCOL''[:''USERNAME'']
you can tell <tt>download_and_compile.sh</tt> that every component fetched from ''SITE'' should be cloned with the specified protocol and username (allowed protocols are <tt>https</tt>, <tt>ssh</tt> and <tt>git</tt>).

{{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:
<pre>
--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</pre>
Here, the site names are <tt>GitHubA</tt> and <tt>GitHubB</tt>; the <tt>--override-repo</tt> option will be presented below.

By default, <tt>download_and_compile.sh</tt> case-insensitively uses the <tt>GitHub</tt> (resp. <tt>SourceForge</tt>) 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''<nowiki>=</nowiki>GitHubA:... or --override-repo ''c''<nowiki>=</nowiki>GitHubB:... has been specified.}}

==== Component-specific settings ====

The <tt>--override-repo</tt> and <tt>--component-branch</tt> options allow one to override the default settings used by <tt>download_and_compile.sh</tt> 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 <tt>download_and_compile.sh</tt> (e.g., <tt>SIMGEAR</tt>—see [[#List of available components|List of available components]]);
* ''ADDRESS'' is something like <tt>git.code.sf.net/p/flightgear/simgear</tt> (don't include any <tt>protocol://</tt> 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; <tt>download_and_compile.sh</tt> uses it to find out how to connect to ''ADDRESS'' in order to clone the repository for ''COMPONENT'' (see [[#Site-specific settings|Site-specific settings]]).
See the [[#A short example|above example]] for a concrete example where these options are used.

{{Note|The argument of any long option of <tt>download_and_compile.sh</tt> 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 <tt>download_and_compile.sh</tt> (October 2020 or later), this can be done for SimGear and FlightGear using the <code>--sg-cmake-arg</code> and <code>--fg-cmake-arg</code> options (the environment variables <tt>SG_CMAKEARGS</tt> and <tt>FG_CMAKEARGS</tt> 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 <tt>CMakeLists.txt</tt> files, for example {{simgear source
| path = CMakeLists.txt
| text = here
}} for SimGear and {{flightgear source
| path = CMakeLists.txt
| text = 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 {{forum link|t=35740|text=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 <code>--sg-cmake-arg</code> and/or <code>--fg-cmake-arg</code> 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 <code>$(...)</code> command substitution.

Using the (half-deprecated) environment variables <tt>SG_CMAKEARGS</tt> and <tt>FG_CMAKEARGS</tt>, 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 <tt>download_and_compile.sh</tt>, 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 <tt>download_and_compile.sh</tt>, 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 <tt>download_and_compile.sh</tt> 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 <tt>download_and_compile.sh</tt> in the directory where it is run, such as <tt>run_fgfs.sh</tt> and <tt>run_fgfs_debug.sh</tt>: these scripts automatically set up the required environment variables according to your build settings before firing the desired program (e.g., <tt>fgfs</tt>) with the arguments you provided.

Therefore, the simplest way to run a FlightGear program built by <tt>download_and_compile.sh</tt> is to launch the <tt>run_fgfs.sh</tt> script that <tt>download_and_compile.sh</tt> created in the directory from which it was run, for example:
$ cd ~/flightgear/dnc-managed
$ ./run_fgfs.sh --launcher

{{Note|<code>./run_fgfs.sh --launcher</code> starts FlightGear with its built-in launcher. If you just do <code>./run_fgfs.sh</code>, 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, [https://en.wikipedia.org/wiki/Paro_Airport 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 <tt>download_and_compile.sh</tt> to maintain several directory trees such as the tree starting at <tt>~/flightgear/dnc-managed</tt> in [[#getting-started-with-download-and-compile-sh|Getting started with <tt>download_and_compile.sh</tt>]] (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 <tt>download_and_compile.sh</tt> 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 <tt>~/flightgear/dnc-managed/install/flightgear/fgdata</tt>. 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 <tt>~/flightgear/dnc-managed/install/flightgear/fgdata</tt>.

{{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 [[Avoiding multiple downloads of FGData on Linux|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|Getting started with <tt>download_and_compile.sh</tt>]].}}

If you wish to get other programs (precisely: download, build and install them), you need to launch <tt>download_and_compile.sh</tt> with the desired component names as arguments. For instance:
$ cd ~/flightgear/dnc-managed
$ download_and_compile.sh SIMGEAR FGFS DATA OSG

See [[#list-of-available-components|above]] for the list of available components.

=== TerraGear ===

Run <tt>download_and_compile.sh</tt> 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 <tt>~/flightgear/dnc-managed</tt>:
* <tt>run_genapts850.sh</tt>
* <tt>run_ogr-decode.sh</tt>
* <tt>run_tg-construct.sh</tt>
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 <tt>download_and_compile.sh</tt> with the TERRAGEARGUI component:
$ cd ~/flightgear/dnc-managed
$ download_and_compile.sh TERRAGEARGUI
This will create a <tt>run_terrageargui.sh</tt> script in <tt>~/flightgear/dnc-managed</tt>, and also a default configuration file <tt>~/.config/TerraGear/TerraGearGUI.conf</tt>, 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 <tt>download_and_compile.sh</tt> to take care of the FGFS component. You can launch the standalone FGCom program by using the <tt>run_fgcom.sh</tt> script:
$ cd ~/flightgear/dnc-managed
$ ./run_fgcom.sh

=== FGRun ===

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

[[File:fgrun-page2.jpg|thumb|right]]
Before FlightGear had its built-in launcher (the one you get with <code>run_fgfs.sh --launcher</code>), many users found comfortable having FlightGear launched by the graphical utility [[Fgrun|FGRun]]. This program is built and installed when <tt>download_and_compile.sh</tt> is run with the FGRUN component. You then have to launch the <tt>run_fgrun.sh</tt> command, for example:
$ cd ~/flightgear/dnc-managed
$ ./run_fgrun.sh

FGRun will save its settings in <tt>~/.fltk/flightgear.org/fgrun.prefs</tt>. 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 <code>run_fgfs.sh --launcher</code>) or [[FFGo]].}}

[[File:Fgo01.jpg|thumb|left]]
FGo! is a graphical utility written in [[python]]. It is downloaded and installed when <tt>download_and_compile.sh</tt> is run with the FGO component. You then have to launch the <tt>run_fgo.sh</tt> 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 <tt>fgfs</tt> 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:
# 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.
# 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.
# 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|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 <tt>download_and_compile.sh</tt> 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 <tt>download_and_compile.sh</tt> script to clean OpenRTI with <code>rm -f CMakeCache.txt && rm -rf CMakeFiles/</code>, or just restart the build in a clean environment. Assuming you are in the base directory from which you ran <tt>download_and_compile.sh</tt>, you can run <code>download_and_compile.sh --cleanup</code> (see [[#Cleaning built and installed files|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 {{forum link|t=26244|text=this thread}} for more details. Note that <tt>download_and_compile.sh</tt> didn't have the <code>--cleanup</code> option at that time!

== Options ==

=== Release selection ===

* Build the latest stable release: <code>-s</code>
* Build the latest Long Term Stable release: <code>--lts</code>
* Build the previous Long Term Stable release: <code>--old-lts</code>

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

If you pass none of <code>-s</code>, <code>--lts</code> and <code>--old-lts</code> in a <tt>download_and_compile.sh</tt> 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, <tt>download_and_compile.sh</tt> 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 <code>--non-interactive</code> option in order to suppress these prompts (technically, this causes the default answer to be automatically used).

=== Cleaning built and installed files ===

Option <code>--cleanup</code> causes <tt>download_and_compile.sh</tt> 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 <code>--cleanup</code> 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 <code>-j x</code> to <tt>download_and_compile.sh</tt> (where ''x'' is the number of your CPU cores you wish to assign to the job) will considerably speed up the compilation steps. Passing <code>-j$(nproc)</code> is a convenient way to automatically use all available cores.

=== Advanced options ===

* Build a release version: <code>-b Release</code>
* Build a version that should run as fast as a release build, yet has debug information that can be used to post backtraces: <code>-b RelWithDebInfo</code> (this is the default)
* Build a full debug version for very complete bug reporting: <code>-b Debug</code>
* Skip download of distro packages (i.e., by default: <tt>apt-get install ...</tt>): <code>-p n</code>
* Skip retrieving of component downloads and updates (which typically use Git or wget): <code>-d n</code>
* Skip the configure step (like running [https://cmake.org/ CMake] or [https://www.gnu.org/software/autoconf/ autoconf]'s <tt>./configure</tt>): <code>-r n</code>
* Skip compilation of programs: <code>-c n</code>
* Build with compositor: <code>--compositor</code>
* Force the use of a particular branch for a given component: <code>--component-branch ''COMPONENT=BRANCH''</code> (e.g., <code>--component-branch OSG=OpenSceneGraph-3.6</code>, <code>--component-branch FGFS=next</code>, etc.—but remember that components FGFS, SIMGEAR and DATA must ''always'' be in sync). See [[#Component-specific settings|Component-specific settings]] for details.
* Override the repository from which a given component is initially fetched: <code>--override-repo ''COMPONENT''=''SITE'':''ADDRESS''</code> (see [[#Component-specific settings|Component-specific settings]]).
* Generate build.ninja files and build using Ninja: <code>-G Ninja</code>
* Run CMake in verbose mode: <code>--verbose</code> (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 <code>-rn</code> option may be necessary, though (this is the case in particular if you added or removed C++ files).

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

Export in environment:
export CMAKE_CXX_COMPILER_LAUNCHER=ccache

Or when running <code>download_and_compile.sh</code> add this option:
--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 <tt>download_and_compile.sh</tt>):
$ sed 's|\./fgfs|optirun ./fgfs|' run_fgfs.sh > run_fgfs_optirun.sh && chmod +x run_fgfs_optirun.sh
Now you can run FlightGear with <code>./run_fgfs_optirun.sh</code>.

The same can be done for the [[FlightGear_Launch_Control|FGRun]] launcher:
$ sed 's|\./fgrun|optirun ./fgrun|' run_fgrun.sh > run_fgrun_optirun.sh && chmod +x run_fgrun_optirun.sh

== See also ==

* {{fgmeta source
| path = compile-scripts
| text = Other FlightGear build scripts
}} present in [[FGMeta]]
* {{fgmeta source
| path = fg-from-scratch
| simplepath = true
}}
* [http://geoffmclane.com/fg/fgfs-052.htm Another script] for building FlightGear and all its dependencies in an automated fashion. The page seems a bit oldish, though (as of 2019).

== References ==
<references/>

[[Category:Building from source]]

[[fr:Script de compilation sous Linux Debian/Ubuntu]]
[[nl:Compileren met een Script op Linux Debian/Ubuntu]]

User:Jebba

2024-11-17T16:33:55Z

Jebba: Initial stub

Jeff Moe

* [https://spacecruft.org Spacecruft]