417
edits
Scripted Compilation on Linux Debian/Ubuntu: Difference between revisions
Jump to navigation
Jump to search
Scripted Compilation on Linux Debian/Ubuntu (view source)
Revision as of 14:03, 11 March 2025
, 11 MarchCanonical download location for download_and_compile.sh is now at GitLab
(→ccache: Think it needs that -D...) |
(Canonical download location for download_and_compile.sh is now at GitLab) |
||
| Line 15: | Line 15: | ||
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. | 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 | 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 {{fgmeta source | ||
| path = download_and_compile.sh | |||
| text = 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 == | == Prerequisites == | ||
| Line 51: | Line 54: | ||
mkdir -p ~/flightgear/dnc-managed | mkdir -p ~/flightgear/dnc-managed | ||
cd ~/flightgear | cd ~/flightgear | ||
<nowiki>git clone https:// | <nowiki>git clone https://gitlab.com/flightgear/fgmeta.git</nowiki> | ||
cd ~/flightgear/dnc-managed | cd ~/flightgear/dnc-managed | ||
~/flightgear/fgmeta/download_and_compile.sh -s -j$(nproc) | ~/flightgear/fgmeta/download_and_compile.sh -s -j$(nproc) | ||
| Line 85: | Line 88: | ||
=== <span id="getting-download-and-compile-sh-using-an-fgmeta-clone"></span> Getting <tt>download_and_compile.sh</tt> the “right way” === | === <span id="getting-download-and-compile-sh-using-an-fgmeta-clone"></span> Getting <tt>download_and_compile.sh</tt> the “right way” === | ||
There are several ways to obtain | There are several ways to obtain {{fgmeta source | ||
| path = download_and_compile.sh | |||
| text = 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: | 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 | $ mkdir -p ~/flightgear | ||
$ cd ~/flightgear | $ cd ~/flightgear | ||
<nowiki>$ git clone -b next https:// | <nowiki>$ git clone -b next https://gitlab.com/flightgear/fgmeta.git</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: | 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 | <pre>$ ~/flightgear/fgmeta/download_and_compile.sh --help | ||
| Line 531: | Line 537: | ||
==== The site name ==== | ==== 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. | <tt>download_and_compile.sh</tt> uses case-insensitive short names such as <tt>GitLab</tt>, <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 ==== | ==== The protocol ==== | ||
| Line 557: | Line 563: | ||
Here, the site names are <tt>GitHubA</tt> and <tt>GitHubB</tt>; the <tt>--override-repo</tt> option will be presented below. | 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> | By default, <tt>download_and_compile.sh</tt> case-insensitively uses the <tt>GitLab</tt> (resp. <tt>SourceForge</tt>) site name to identify the settings used when cloning a repository from gitlab.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 ==== | ==== Component-specific settings ==== | ||
| Line 567: | Line 573: | ||
In this syntax: | 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]]); | * ''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> | * ''ADDRESS'' is something like <tt>gitlab.com/flightgear/simgear.git</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''; | * ''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]]). | * ''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]]). | ||