Sophie

Sophie

distrib > Mageia > 7 > i586 > by-pkgid > d6f7efeccd6357dee2d9e377a80873ab > files > 7

flatpak-builder-1.0.7-1.mga7.i586.rpm

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Flatpak Builder Command Reference</title><link rel="stylesheet" type="text/css" href="docbook.css" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /></head><body><div class="reference"><div class="titlepage"><div><div><h1 class="title"><a id="idp295825732"></a>Flatpak Builder Command Reference</h1></div><div><p class="releaseinfo">Version 1.0.7</p></div></div><hr /></div><div class="important" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Important</h3><p>
          The command reference is generated from the flatpak-builder repo; see <a class="ulink" href="https://github.com/flatpak/flatpak-builder/tree/master/doc" target="_top">https://github.com/flatpak/flatpak-builder/tree/master/doc</a>
        </p></div><div class="partintro"><div></div><p>
        Flatpak-builder is a tool to build flatpak applications.
      </p><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="chapter"><a href="#idp297356228">Executables</a></span></dt><dd><dl><dt><span class="refentrytitle"><a href="#flatpak-builder">flatpak-builder</a></span><span class="refpurpose"> — Help build application dependencies</span></dt></dl></dd><dt><span class="chapter"><a href="#idp297356868">File Formats</a></span></dt><dd><dl><dt><span class="refentrytitle"><a href="#flatpak-manifest">flatpak manifest</a></span><span class="refpurpose"> — Information for building an application</span></dt></dl></dd></dl></div></div><div class="chapter"><div class="titlepage"><div><div><h2 class="title"><a id="idp297356228"></a>Executables</h2></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="refentrytitle"><a href="#flatpak-builder">flatpak-builder</a></span><span class="refpurpose"> — Help build application dependencies</span></dt></dl></div><div class="refentry"><a id="flatpak-builder"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>flatpak-builder — Help build application dependencies</p></div><div class="refsynopsisdiv"><h2>Synopsis</h2><div class="cmdsynopsis"><p><code class="command">flatpak-builder</code>  [OPTION...]  DIRECTORY   MANIFEST </p></div><div class="cmdsynopsis"><p><code class="command">flatpak-builder</code>   --run  [OPTION...]  DIRECTORY   MANIFEST   COMMAND </p></div><div class="cmdsynopsis"><p><code class="command">flatpak-builder</code>   --show-deps  [OPTION...]  MANIFEST </p></div></div><div class="refsect1"><a id="idp300392372"></a><h2>Description</h2><p>
            <span class="command"><strong>flatpak-builder</strong></span> is a wrapper around the <span class="command"><strong>flatpak build</strong></span> command
            that automates the building of applications and their dependencies. It is one option you can use
            to build applications.
        </p><p>
            The goal of <span class="command"><strong>flatpak-builder</strong></span> is to push as much knowledge about how to build modules to
            the individual upstream projects. It does this by assuming that the modules adhere to the Build API specified
            at https://github.com/cgwalters/build-api. This essentially  means that it follows the <span class="command"><strong>./configure
            &amp;&amp; make &amp;&amp; make install</strong></span> scheme with an optional autogen script. If the upstream
            does not adhere to the API you can make it do so by adding patches and extra files.
        </p><p>
            An invocation of <span class="command"><strong>flatpak-builder</strong></span> proceeds in these stages, each being specified
            in detail in json format in   MANIFEST :
            </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: bullet; "><li class="listitem" style="list-style-type: disc"><p>Download all sources</p></li><li class="listitem" style="list-style-type: disc"><p>Initialize the application directory with <span class="command"><strong>flatpak build-init</strong></span></p></li><li class="listitem" style="list-style-type: disc"><p>Build and install each module with <span class="command"><strong>flatpak build</strong></span></p></li><li class="listitem" style="list-style-type: disc"><p>Clean up the final build tree by removing unwanted files and e.g. stripping binaries</p></li><li class="listitem" style="list-style-type: disc"><p>Finish the application directory with <span class="command"><strong>flatpak build-finish</strong></span></p></li></ul></div><p>

            After this you will end up with a build of the application in   DIRECTORY , which you can
            export to a repository with the <span class="command"><strong>flatpak build-export</strong></span> command. If you use the <code class="option">--repo</code>
            option, flatpak-builder will do the export for you at the end of the build process. When flatpak-builder does the
            export, it also stores the manifest that was used for the build in /app/manifest.json. The manifest is 'resolved',
            i.e. git branch names are replaced by the actual commit IDs that were used in the build.
        </p><p>
            At each of the above steps flatpak caches the result, and if you build the same file again, it will start
            at the first step where something changes. For instance the first version controlled source that had
            new commits added, or the first module where some changes to the  MANIFEST  file caused
            the build environment to change. This makes flatpak-builder very efficient for incremental builds.
        </p><p>
            When building a flatpak to be published to the internet,
            <code class="option">--collection-id=COLLECTION-ID</code> should be specified
            as a globally unique reverse DNS value to identify the collection of
            flatpaks this will be added to. Setting a globally unique collection
            ID allows the apps in the repository to be shared over peer to peer
            systems without needing further configuration.
        </p></div><div class="refsect1"><a id="idp300402244"></a><h2>Manifest</h2><p>The manifest file is a json or yaml file whose format is described in detail in its own manual page.</p></div><div class="refsect1"><a id="idp300402900"></a><h2>Options</h2><p>The following options are understood:</p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="option">-h</code>, </span><span class="term"><code class="option">--help</code></span></dt><dd><p>
                    Show help options and exit.
                </p></dd><dt><span class="term"><code class="option">-v</code>, </span><span class="term"><code class="option">--verbose</code></span></dt><dd><p>
                    Print debug information during command processing.
                </p></dd><dt><span class="term"><code class="option">--version</code></span></dt><dd><p>
                    Print version information and exit.
                </p></dd><dt><span class="term"><code class="option">--arch=ARCH</code></span></dt><dd><p>
                    Specify the machine architecture to build for. If no architecture is specified, the host architecture will be automatically detected. Only host compatible architectures can be specified.
                </p></dd><dt><span class="term"><code class="option">--default-branch=<em class="replaceable"><code>BRANCH</code></em></code></span></dt><dd><p>
                    Set the default branch to
                    <em class="replaceable"><code>BRANCH</code></em>. This is used if
                    the manifest does not specify a branch. The default
                    is <code class="literal">master</code>.
                </p></dd><dt><span class="term"><code class="option">--disable-cache</code></span></dt><dd><p>
                    Don't look at the existing cache for a previous build, instead always rebuild modules.
                </p></dd><dt><span class="term"><code class="option">--disable-rofiles-fuse</code></span></dt><dd><p>
                    Disable the use of rofiles-fuse to optimize the cache use via hardlink checkouts.
                </p></dd><dt><span class="term"><code class="option">--disable-download</code></span></dt><dd><p>
                     Don't download any sources. This only works if some version of all sources are downloaded
                     already. This is useful if you want to guarantee that no network i/o is done. However, the
                     build will fail if some source is not locally available.
                </p></dd><dt><span class="term"><code class="option">--disable-updates</code></span></dt><dd><p>
                  Download missing sources, but don't update local mirrors of version control repos. This is useful
                  to rebuild things but without updating git, bzr or svn repositories from the remote repository.
                </p></dd><dt><span class="term"><code class="option">--disable-tests</code></span></dt><dd><p>
                    Don't run any of the tests.
                </p></dd><dt><span class="term"><code class="option">--run</code></span></dt><dd><p>
                  Run a command in a sandbox based on the build dir. This starts flatpak build, with some extra
                  arguments to give the same environment as the build, and the same permissions the final app
                  will have. The command to run must be the last argument passed to
                  flatpak-builder, after the directory and the manifest.
                  </p><p>
                  Only the
                  <code class="option">--arch=</code><em class="replaceable"><code>ARCH</code></em>,
                  <code class="option">--ccache</code> and
                  <code class="option">--verbose</code> options can be combined
                  with this option.
                  </p></dd><dt><span class="term"><code class="option">--build-shell=MODULENAME</code></span></dt><dd><p>
                  Extract and prepare the sources for the named module, and then start
                  a shell in a sandbox identical to the one flatpak-builder would use for building the module.
                  This is useful to debug a module.
                </p></dd><dt><span class="term"><code class="option">--show-deps</code></span></dt><dd><p>
                  List all the (local) files that the manifest depends on.
                  </p><p>
                  Only the <code class="option">--verbose</code> option can be combined
                  with this option.
                  </p></dd><dt><span class="term"><code class="option">--download-only</code></span></dt><dd><p>
                     Exit successfully after downloading the required sources.
                </p></dd><dt><span class="term"><code class="option">--bundle-sources</code></span></dt><dd><p>
                    Create an additional runtime with the source code for
                    this module. It will be named
                    <em class="replaceable"><code>app-id</code></em><code class="literal">.Sources</code>,
                    for example
                    <code class="literal">org.gnome.Maps.Sources</code>.
                </p></dd><dt><span class="term"><code class="option">--build-only</code></span></dt><dd><p>
                     Don't do the cleanup and finish stages, which is useful if you
                     want to build more things into the app.
                </p></dd><dt><span class="term"><code class="option">--finish-only</code></span></dt><dd><p>
                     Only do the cleanup, finish and export stages, picking up
                     where a --build-only command left off.
                </p></dd><dt><span class="term"><code class="option">--export-only</code></span></dt><dd><p>
                    Only do the export stages, picking up the build result from a previous build.
                    This can be used to split the build and export/signature into two calls
                    by leaving out --repo in the first call.
                </p></dd><dt><span class="term"><code class="option">--require-changes</code></span></dt><dd><p>
                    Do nothing, leaving a non-existent  DIRECTORY  if nothing changes since
                    last cached build. If this is not specified, the latest version from the cache will be put
                    into   DIRECTORY .
                </p></dd><dt><span class="term"><code class="option">--state-dir=PATH</code></span></dt><dd><p>
                  Use this directory for storing state (downloads, build dirs, build cache, etc) rather than
                  .flatpak-builder. This can be an absolute or relative path, but must be on the
                  same filesystem as the specified target  DIRECTORY .
                </p></dd><dt><span class="term"><code class="option">--keep-build-dirs</code></span></dt><dd><p>
                    Don't remove the sources and build after having built and installed each module.
                    This also creates a symlink to the build directory with a stable name ("build-modulename").
                </p></dd><dt><span class="term"><code class="option">--delete-build-dirs</code></span></dt><dd><p>
                    Always remove the sources and build after having built each module, even if the build
                    failed. The default is to keep failed build directories but remove successful ones.
                    This is useful in e.g. automatic build systems.
                </p></dd><dt><span class="term"><code class="option">--ccache</code></span></dt><dd><p>
                     Enable use of ccache in the build (needs ccache in the sdk)
                </p></dd><dt><span class="term"><code class="option">--stop-at=MODULENAME</code></span></dt><dd><p>
                     Stop at the specified module, ignoring it and all the following ones
                     in both the "download" and "build" phases. This is useful for debugging
                     and development. For instance, you can build all the dependencies, but
                     stop at the main application so that you can then do a build from a
                     pre-existing checkout. Implies --build-only.
                </p></dd><dt><span class="term"><code class="option">--repo=DIR</code></span></dt><dd><p>
                    When build is done, run export the result to this repository.
                </p></dd><dt><span class="term"><code class="option">-s</code>, </span><span class="term"><code class="option">--subject=SUBJECT</code></span></dt><dd><p>
                    One line subject for the commit message.
                    Used when exporting the build results.
                </p></dd><dt><span class="term"><code class="option">-b</code>, </span><span class="term"><code class="option">--body=BODY</code></span></dt><dd><p>
                    Full description for the commit message.
                    Used when exporting the build results.
                </p></dd><dt><span class="term"><code class="option">--collection-id=COLLECTION-ID</code></span></dt><dd><p>
                    Set as the collection ID of the repository. Setting a globally
                    unique collection ID allows the apps in the repository to be shared over
                    peer to peer systems without needing further configuration.
                    If building in an existing repository, the collection ID
                    must match the existing configured collection ID for that
                    repository.
                </p></dd><dt><span class="term"><code class="option">--gpg-sign=KEYID</code></span></dt><dd><p>
                    Sign the commit with this GPG key.
                    Used when exporting the build results.
                    This option can be used multiple times.
                </p></dd><dt><span class="term"><code class="option">--gpg-homedir=PATH</code></span></dt><dd><p>
                    GPG Homedir to use when looking for keyrings.
                    Used when exporting the build results.
                </p></dd><dt><span class="term"><code class="option">--jobs=JOBS</code></span></dt><dd><p>
                     Limit the number of parallel jobs during the build.
                     The default is the number of CPUs on the machine.
                </p></dd><dt><span class="term"><code class="option">--force-clean</code></span></dt><dd><p>
                    Erase the previous contents of DIRECTORY if it is
                    not empty.
                </p></dd><dt><span class="term"><code class="option">--sandbox</code></span></dt><dd><p>
                    Disable the possibility to specify build-args that
                    are passed to flatpak build. This means the build
                    process can't break out of its sandbox, and is
                    useful when building less trusted software.
                </p></dd><dt><span class="term"><code class="option">--allow-missing-runtimes</code></span></dt><dd><p>
                    Do not immediately fail if the sdk or platform runtimes
                    are not installed on this system. Attempting to build any
                    manifest modules will still fail if the sdk is missing, but
                    may be useful for apps that install files without a sandbox
                    build.
                </p></dd><dt><span class="term"><code class="option">--rebuild-on-sdk-change</code></span></dt><dd><p>
                  Record the exact version of the sdk in the cache, and rebuild everything
                  if it changes. This is useful if you're building against an API-unstable
                  runtime, like a nightly build.
                </p></dd><dt><span class="term"><code class="option">--skip-if-unchanged</code></span></dt><dd><p>
                  If the json is unchanged since the last build of this filename, then
                  do nothing, and return exit code 42.
                </p></dd><dt><span class="term"><code class="option">--mirror-screenshots-url=URL</code></span></dt><dd><p>
                  Mirror any screenshots in the appstream and rewrite the appstream xml
                  as if they were on the specified URL. The resulting files will
                  be stored in the "screenshots" subdirectory in the app directory
                  and needs to be copied to the specified URL for the appdata to work.
                </p></dd><dt><span class="term"><code class="option">--extra-sources=SOURCE-DIR</code></span></dt><dd><p>
                  When downloading sources (archives, files, git, bzr, svn), look in this
                  directory for pre-existing copies and use them instead of downloading.
                </p></dd><dt><span class="term"><code class="option">--extra-sources-url=URL</code></span></dt><dd><p>
                  When downloading sources (archives, files, git, bzr, svn), look at this url
                  for mirrored downloads before downloading from the original url.
                </p></dd><dt><span class="term"><code class="option">--from-git=GIT</code></span></dt><dd><p>
                  Look for the manifest in the given git repository. If this option is
                  given, MANIFEST is interpreted as a relative path inside the repository.
                </p></dd><dt><span class="term"><code class="option">--from-git-branch=BRANCH</code></span></dt><dd><p>
                  The branch to use with --from-git.
                </p></dd><dt><span class="term"><code class="option">--no-shallow-clone</code></span></dt><dd><p>
                  Don't use shallow clones when mirroring git repos.
                </p></dd><dt><span class="term"><code class="option">--add-tag=TAG</code></span></dt><dd><p>
                  Add this tag to the tags list of the manifest before building.
                </p></dd><dt><span class="term"><code class="option">--remove-tag=TAG</code></span></dt><dd><p>
                  Remove this tag to the tags list of the manifest before building. The remove
                  happen before processing the --add-tag option, so if both are specified, then
                  --app-tag wins.
                </p></dd><dt><span class="term"><code class="option">--install-deps-from=REMOTE</code></span></dt><dd><p>
                    Install/update build required dependencies from the specified remote.
                </p></dd><dt><span class="term"><code class="option">--install-deps-only</code></span></dt><dd><p>
                    Stop after downloading dependencies.
                </p></dd><dt><span class="term"><code class="option">--install</code></span></dt><dd><p>
                    When the build is finished, install the result locally.
                </p></dd><dt><span class="term"><code class="option">--user</code></span></dt><dd><p>
                    Install the dependencies in a per-user installation.
                </p></dd><dt><span class="term"><code class="option">--system</code></span></dt><dd><p>
                    Install the dependencies in the default system-wide installation.
                </p></dd><dt><span class="term"><code class="option">--installation=NAME</code></span></dt><dd><p>
                    Install the dependencies in a system-wide installation
                    specified by  NAME  among those defined in
                    <code class="filename">/etc/flatpak/installations.d/</code>. Using
                      --installation=default  is equivalent to using
                      --system .
                </p></dd></dl></div></div><div class="refsect1"><a id="idp300455444"></a><h2>Caching</h2><p>
            flatpak-builder caches sources and partial build results
            in the state directory (defaulting to the .flatpak-builder
            subdirectory of the current directory). If you use
            <code class="option">--keep-build-dirs</code>, build directories for
            each module are also stored here.
        </p><p>
            It is safe to remove the state directory. This will force a full build the next time you build.
        </p></div><div class="refsect1"><a id="idp300456724"></a><h2>Examples</h2><p>
            <span class="command"><strong>$ flatpak-builder my-app-dir manifest.json</strong></span>
        </p><p>
            Example manifest file:
        </p><pre class="programlisting">
{
    "id": "org.test.TestApp",
    "runtime": "org.freedesktop.Platform",
    "runtime-version": "1.2",
    "sdk": "org.freedesktop.Sdk",
    "command": "test",
    "cleanup": [ "/include", "*.la" ],
    "build-options" : {
        "cflags": "-O2 -g",
        "cxxflags": "-O2 -g",
        "env": {
            "V": "1"
        },
        "arch": {
            "x86_64": {
                "cflags": "-O3 -g",
            }
        }
    },
    "modules": [
        {
            "name": "pygobject",
            "config-opts": [ "--disable-introspection" ],
            "sources": [
                {
                    "type": "archive",
                    "url": "http://ftp.gnome.org/pub/GNOME/sources/pygobject/2.28/pygobject-2.28.6.tar.xz",
                    "sha256": "fb8a1d4f665130a125011659bd347c7339c944232163dbb9a34fd0686577adb8"
                },
                {
                    "type": "patch",
                    "path": "required-pygobject-fix.patch"
                },
                {
                    "type": "file",
                    "path": "pygobject-extra-file",
                    "dest-filename": "extra-file"
                }
            ]
        },
        {
            "name": "babl",
            "build-options" : { "cxxflags": "-O2 -g -std=c++11" },
            "cleanup": [ "/bin" ],
            "sources": [
                {
                    "type": "git",
                    "url": "https://gitlab.gnome.org/GNOME/babl.git"
                }
            ]
        },
        {
            "name": "testapp",
            "sources": [
                {
                    "type": "bzr",
                    "url": "lp:testapp"
                }
            ]
        }
    ]
}
</pre></div><div class="refsect1"><a id="idp301965396"></a><h2>See also</h2><p>
            <a class="citerefentry" href="#flatpak"><span class="citerefentry"><span class="refentrytitle">flatpak</span>(1)</span></a>,
            <a class="citerefentry" href="#flatpak-manifest"><span class="citerefentry"><span class="refentrytitle">flatpak-manifest</span>(5)</span></a>,
            <a class="citerefentry" href="#flatpak-build-init"><span class="citerefentry"><span class="refentrytitle">flatpak-build-init</span>(1)</span></a>,
            <a class="citerefentry" href="#flatpak-build"><span class="citerefentry"><span class="refentrytitle">flatpak-build</span>(1)</span></a>,
            <a class="citerefentry" href="#flatpak-build-finish"><span class="citerefentry"><span class="refentrytitle">flatpak-build-finish</span>(1)</span></a>,
            <a class="citerefentry" href="#flatpak-build-export"><span class="citerefentry"><span class="refentrytitle">flatpak-build-export</span>(1)</span></a>
        </p></div></div></div><div class="chapter"><div class="titlepage"><div><div><h2 class="title"><a id="idp297356868"></a>File Formats</h2></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="refentrytitle"><a href="#flatpak-manifest">flatpak manifest</a></span><span class="refpurpose"> — Information for building an application</span></dt></dl></div><div class="refentry"><a id="flatpak-manifest"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>flatpak-manifest — Information for building an application</p></div><div class="refsect1"><a id="idp301281908"></a><h2>Description</h2><p>
          Flatpak uses manifest, or recipe, files in a json or yaml format to describe how an
          application and its bundled dependencies can be built from sources. The manifest
          gets used by flatpak-builder.
       </p></div><div class="refsect1"><a id="idp301745108"></a><h2>File format</h2><p>
          The top level of the manifest file describes global attributes of the application, how
          it can be built, and the list of modules that need to be built.
        </p><div class="refsect2"><a id="idp301745876"></a><h3>Toplevel properties</h3><p>
          These are the properties that are accepted:
        </p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="option">id</code> or <code class="option">app-id</code> (string)</span></dt><dd><p>A string defining the application id.</p></dd><dt><span class="term"><code class="option">branch</code> (string)</span></dt><dd><p>The branch to use when exporting
                    the application. If this is unset the defaults
                    come from the default-branch option.</p><p>This key overrides both the default-branch
                    key, and the --default-branch commandline
                    option. Unless you need a very specific branchname
                    (like for a runtime or an extension) it is
                    recommended to use the default-branch key instead, because
                    you can then override the default using --default-branch when
                    building for instance a test build.</p></dd><dt><span class="term"><code class="option">default-branch</code> (string)</span></dt><dd><p>The default branch to use when
                    exporting the application. Defaults to master. </p><p>This key can be overriden by the
                    --default-branch commandline
                    option.</p></dd><dt><span class="term"><code class="option">collection-id</code> (string)</span></dt><dd><p>The collection ID of the repository,
                    defaults to being unset. Setting a globally
                    unique collection ID allows the apps in the repository to be shared over
                    peer to peer systems without needing further configuration.
                    If building in an existing repository, the collection ID
                    must match the existing configured collection ID for that
                    repository.</p></dd><dt><span class="term"><code class="option">extension-tag</code> (string)</span></dt><dd><p>If building an extension, the tag for the extension
                    point to use. Since flatpak 0.11.4 a runtime may define multiple
                    locations for the same extension point with the intention that
                    different branches for the extension are mounted at each location. When
                    building an extension it is necessary to know what extension point to
                    install the extension to. This option resolves any ambiguity
                    in which extension point to choose. If not specified, the default choice
                    is to install into either the only location for the extension point or
                    into the location for the untagged extension point. If there are multiple
                    locations for the same extension point defined with different tags
                    then an error will occur.</p></dd><dt><span class="term"><code class="option">runtime</code> (string)</span></dt><dd><p>The name of the runtime that the application uses.</p></dd><dt><span class="term"><code class="option">runtime-version</code> (string)</span></dt><dd><p>The version of the runtime that the application uses, defaults to master.</p></dd><dt><span class="term"><code class="option">sdk</code> (string)</span></dt><dd><p>The name of the development runtime that the application builds with.</p></dd><dt><span class="term"><code class="option">var</code> (string)</span></dt><dd><p>Initialize the (otherwise empty) writable /var in the build with a copy of this runtime.</p></dd><dt><span class="term"><code class="option">metadata</code> (string)</span></dt><dd><p>Use this file as the base metadata file when finishing.</p></dd><dt><span class="term"><code class="option">command</code> (string)</span></dt><dd><p>
                        The filename or path to the main binary of the application. Note that this
                        is really just a single file, not a commandline. If you want to pass arguments,
                        install a shell script wrapper and use that as the command.
                    </p><p>
                        Also note that the command is used when the application is run via
                        <span class="command"><strong>flatpak run</strong></span>, and does not affect what gets executed when
                        the application is run in other ways, e.g. via the desktop file or D-Bus
                        activation.
                    </p></dd><dt><span class="term"><code class="option">build-runtime</code> (boolean)</span></dt><dd><p>Build a new runtime instead of an application.</p></dd><dt><span class="term"><code class="option">build-extension</code> (boolean)</span></dt><dd><p>Build an extension.</p></dd><dt><span class="term"><code class="option">separate-locales</code> (boolean)</span></dt><dd><p>Separate out locale files and translations to an extension runtime. Defaults to true.</p></dd><dt><span class="term"><code class="option">id-platform</code> (string)</span></dt><dd><p>When building a runtime sdk, also create a platform based on it with this id.</p></dd><dt><span class="term"><code class="option">metadata-platform</code> (string)</span></dt><dd><p>The metadata file to use for the platform we create.</p></dd><dt><span class="term"><code class="option">writable-sdk</code> (boolean)</span></dt><dd><p>If true, use a writable copy of the sdk for /usr.
                    Defaults to true if build-runtime is specified.</p></dd><dt><span class="term"><code class="option">appstream-compose</code> (boolean)</span></dt><dd><p>Run appstream-compose during cleanup phase. Defaults to true.</p></dd><dt><span class="term"><code class="option">sdk-extensions</code> (array of strings)</span></dt><dd><p>Install these extra sdk extensions in /usr.</p></dd><dt><span class="term"><code class="option">platform-extensions</code> (array of strings)</span></dt><dd><p>Install these extra sdk extensions when creating the platform.</p></dd><dt><span class="term"><code class="option">base</code> (string)</span></dt><dd><p>Start with the files from the specified application. This can be
                    used to create applications that extend another application.</p></dd><dt><span class="term"><code class="option">base-version</code> (string)</span></dt><dd><p>Use this specific version of the application specified in base.
                    If unspecified, this uses the value specified in branch</p></dd><dt><span class="term"><code class="option">base-extensions</code> (array of strings)</span></dt><dd><p>Install these extra extensions from the base application when initializing
                    the application directory.</p></dd><dt><span class="term"><code class="option">inherit-extensions</code> (array of strings)</span></dt><dd><p>Inherit these extra extensions points from the base application or sdk when
                    finishing the build.</p></dd><dt><span class="term"><code class="option">inherit-sdk-extensions</code> (array of strings)</span></dt><dd><p>Inherit these extra extensions points from the base application or sdk when
                    finishing the build, but do not inherit them into the platform.</p></dd><dt><span class="term"><code class="option">tags</code> (array of strings)</span></dt><dd><p>Add these tags to the metadata file.</p></dd><dt><span class="term"><code class="option">build-options</code> (object)</span></dt><dd><p>Object specifying the build environment. See below for details.</p></dd><dt><span class="term"><code class="option">modules</code> (array of objects or strings)</span></dt><dd><p>An array of objects specifying the modules to be built in order.
                    String members in the array are interpreted as the name of a separate json or yaml file that contains a module.
                    See below for details.</p></dd><dt><span class="term"><code class="option">add-extensions</code> (objects)</span></dt><dd><p>This is a dictionary of extension objects. The key is the name of the extension. See below for details.</p></dd><dt><span class="term"><code class="option">add-build-extensions</code> (objects)</span></dt><dd><p>This is a dictionary of extension objects similar to add-extensions. The main difference is that the extensions are added early and are available for use during the build.</p></dd><dt><span class="term"><code class="option">cleanup</code> (array of strings)</span></dt><dd><p>An array of file patterns that should be removed at the end.
                    Patterns starting with / are taken to be full pathnames (without the /app prefix), otherwise they just match
                    the basename.</p></dd><dt><span class="term"><code class="option">cleanup-commands</code> (array of strings)</span></dt><dd><p>An array of commandlines that are run during the cleanup phase.</p></dd><dt><span class="term"><code class="option">cleanup-platform</code> (array of strings)</span></dt><dd><p>Extra files to clean up in the platform.</p></dd><dt><span class="term"><code class="option">cleanup-platform-commands</code> (array of strings)</span></dt><dd><p>An array of commandlines that are run during the cleanup phase of the platform.</p></dd><dt><span class="term"><code class="option">prepare-platform-commands</code> (array of strings)</span></dt><dd><p>An array of commandlines that are run after importing the base platform, but before applying the new files from the sdk. This is a good place to e.g. delete things from the base that may conflict with the files added in the sdk. </p></dd><dt><span class="term"><code class="option">finish-args</code> (array of strings)</span></dt><dd><p>An array of arguments passed to the <span class="command"><strong>flatpak build-finish</strong></span> command.</p></dd><dt><span class="term"><code class="option">rename-desktop-file</code> (string)</span></dt><dd><p>Any desktop file with this name will be renamed to a name based on id during the cleanup phase.</p></dd><dt><span class="term"><code class="option">rename-appdata-file</code> (string)</span></dt><dd><p>Any appdata file with this name will be renamed to a name based on id during the cleanup phase.</p></dd><dt><span class="term"><code class="option">rename-icon</code> (string)</span></dt><dd><p>Any icon with this name will be renamed to a name based on id during the cleanup phase. Note that this is the icon name, not the full filenames, so it should not include a filename extension. </p></dd><dt><span class="term"><code class="option">appdata-license</code> (string)</span></dt><dd><p>Replace the appdata
                    project_license field with this string. This is
                    useful as the upstream license is typically only
                    about the application itself, whereas the bundled
                    app can contain other licenses
                    too. </p></dd><dt><span class="term"><code class="option">copy-icon</code> (boolean)</span></dt><dd><p>If rename-icon is set, keep a copy of the old icon file.</p></dd><dt><span class="term"><code class="option">desktop-file-name-prefix</code> (string)</span></dt><dd><p>This string will be prefixed to the Name key in the main application desktop file.</p></dd><dt><span class="term"><code class="option">desktop-file-name-suffix</code> (string)</span></dt><dd><p>This string will be suffixed to the Name key in the main application desktop file.</p></dd></dl></div></div><div class="refsect2"><a id="idp299419876"></a><h3>Build Options</h3><p>
                Build options specify the build environment of a module, and can be specified globally as
                well as per-module. Options can also be specified on a per-architecture basis using the arch property.
            </p><p>
                These are the properties that are accepted:
            </p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="option">cflags</code> (string)</span></dt><dd><p>This is set in the environment variable CFLAGS during the build. Multiple specifications of this (in e.g. per-arch area) are concatenated, separated by spaces.</p></dd><dt><span class="term"><code class="option">cflags-override</code> (boolean)</span></dt><dd><p>If this is true, clear cflags from previous build options before adding it from these options.</p></dd><dt><span class="term"><code class="option">cppflags</code> (string)</span></dt><dd><p>This is set in the environment variable CPPFLAGS during the build. Multiple specifications of this (in e.g. per-arch area) are concatenated, separated by spaces.</p></dd><dt><span class="term"><code class="option">cppflags-override</code> (boolean)</span></dt><dd><p>If this is true, clear cppflags from previous build options before adding it from these options.</p></dd><dt><span class="term"><code class="option">cxxflags</code> (string)</span></dt><dd><p>This is set in the environment variable CXXFLAGS during the build. Multiple specifications of this (in e.g. per-arch area) are concatenated, separated by spaces.</p></dd><dt><span class="term"><code class="option">cxxflags-override</code> (boolean)</span></dt><dd><p>If this is true, clear cxxflags from previous build options before adding it from these options.</p></dd><dt><span class="term"><code class="option">ldflags</code> (string)</span></dt><dd><p>This is set in the environment variable LDFLAGS during the build. Multiple specifications of this (in e.g. per-arch area) are concatenated, separated by spaces.</p></dd><dt><span class="term"><code class="option">ldflags-override</code> (boolean)</span></dt><dd><p>If this is true, clear ldflags from previous build options before adding it from these options.</p></dd><dt><span class="term"><code class="option">prefix</code> (string)</span></dt><dd><p>The build prefix for the modules (defaults to <code class="filename">/app</code> for
                    applications and <code class="filename">/usr</code> for runtimes).</p></dd><dt><span class="term"><code class="option">libdir</code> (string)</span></dt><dd><p>The build libdir for the modules (defaults to <code class="filename">/app/lib</code> for
                    applications and <code class="filename">/usr/lib</code> for runtimes).</p></dd><dt><span class="term"><code class="option">append-path</code> (string)</span></dt><dd><p>This will get appended to PATH in the build environment (with an leading colon if
                    needed).</p></dd><dt><span class="term"><code class="option">prepend-path</code> (string)</span></dt><dd><p>This will get prepended to PATH in the build environment (with an trailing colon if
                    needed).</p></dd><dt><span class="term"><code class="option">append-ld-library-path</code> (string)</span></dt><dd><p>This will get appended to LD_LIBRARY_PATH in the build environment (with an leading colon if
                    needed).</p></dd><dt><span class="term"><code class="option">prepend-ld-library-path</code> (string)</span></dt><dd><p>This will get prepended to LD_LIBRARY_PATH in the build environment (with an trailing colon if
                    needed).</p></dd><dt><span class="term"><code class="option">append-pkg-config-path</code> (string)</span></dt><dd><p>This will get appended to PKG_CONFIG_PATH in the build environment (with an leading colon if
                    needed).</p></dd><dt><span class="term"><code class="option">prepend-pkg-config-path</code> (string)</span></dt><dd><p>This will get prepended to PKG_CONFIG_PATH in the build environment (with an trailing colon if
                    needed).</p></dd><dt><span class="term"><code class="option">env</code> (object)</span></dt><dd><p>This is a dictionary defining environment variables to be set during the build. Elements in this override the properties that set the environment, like cflags and ldflags. Keys with a null value unset the corresponding variable. </p></dd><dt><span class="term"><code class="option">build-args</code> (array of strings)</span></dt><dd><p>This is an array containing extra options to pass to flatpak build.</p></dd><dt><span class="term"><code class="option">test-args</code> (array of strings)</span></dt><dd><p>Similar to build-args but affects the tests, not the normal build.</p></dd><dt><span class="term"><code class="option">config-opts</code> (array of strings)</span></dt><dd><p>This is an array containing extra options to pass to configure.</p></dd><dt><span class="term"><code class="option">make-args</code> (array of strings)</span></dt><dd><p>An array of extra arguments that will be passed to make</p></dd><dt><span class="term"><code class="option">make-install-args</code> (array of strings)</span></dt><dd><p>An array of extra arguments that will be passed to make install</p></dd><dt><span class="term"><code class="option">strip</code> (boolean)</span></dt><dd><p>If this is true (the default is false) then all ELF files will be stripped after install.</p></dd><dt><span class="term"><code class="option">no-debuginfo</code> (boolean)</span></dt><dd><p>By default (if strip is not true) flatpak-builder extracts all debug info in ELF files to a separate files
                    and puts this in an extension. If you want to disable this, set no-debuginfo to true.</p></dd><dt><span class="term"><code class="option">no-debuginfo-compression</code> (boolean)</span></dt><dd><p>By default when extracting debuginfo we compress the debug sections. If you want to disable this, set no-debuginfo-compression to true.</p></dd><dt><span class="term"><code class="option">arch</code> (object)</span></dt><dd><p>This is a dictionary defining for each arch a separate build options object that override the main one.</p></dd></dl></div></div><div class="refsect2"><a id="idp299446068"></a><h3>Extension</h3><p>
              Extension define extension points in the app/runtime that can be implemented by extensions, supplying extra files
              which are available during runtime..
            </p><p>
                These are the properties that are accepted:
            </p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="option">directory</code> (string)</span></dt><dd><p>
                      The directory where the extension is mounted.
                      If the extension point is for an application, this path is relative to /app,
                      otherwise it is relative to /usr.
                    </p></dd><dt><span class="term"><code class="option">bundle</code> (boolean)</span></dt><dd><p>If this is true, then the data
                    created in the extension directory is omitted from
                    the result, and instead packaged in a separate
                    extension.</p></dd><dt><span class="term"><code class="option">remove-after-build</code> (boolean)</span></dt><dd><p>If this is true, the extension is
                    removed during when finishing. This is only
                    interesting for extensions in the
                    add-build-extensions property.</p></dd></dl></div><p>
              Additionally the standard flatpak extension properies
              are supported, and put directly into the metadata file:
              autodelete, no-autodownload, subdirectories,
              add-ld-path, download-if, enable-if, merge-dirs,
              subdirectory-suffix, locale-subset, version, versions.
              See the flatpak metadata documentation for more information on these.
            </p></div><div class="refsect2"><a id="idp299450612"></a><h3>Module</h3><p>
                Each module specifies a source that has to be separately built and installed. It contains
                the build options and a list of sources to download and extract before building.
            </p><p>
                Modules can be nested, in order to turn related modules on and off with a single key.
            </p><p>
                These are the properties that are accepted:
            </p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="option">name</code> (string)</span></dt><dd><p>The name of the module, used in e.g. build logs. The name is also used for constructing filenames and commandline arguments, therefore using spaces or '/' in this string is a bad idea.</p></dd><dt><span class="term"><code class="option">disabled</code> (boolean)</span></dt><dd><p>If true, skip this module</p></dd><dt><span class="term"><code class="option">sources</code> (array of objects or strings)</span></dt><dd><p>An array of objects defining
                    sources that will be downloaded and extracted in
                    order. String members in the array are interpreted
                    as the name of a separate json or yaml file that contains
                    sources.  See below for details.</p></dd><dt><span class="term"><code class="option">config-opts</code> (array of strings)</span></dt><dd><p>An array of options that will be passed to configure</p></dd><dt><span class="term"><code class="option">make-args</code> (array of strings)</span></dt><dd><p>An array of arguments that will be passed to make</p></dd><dt><span class="term"><code class="option">make-install-args</code> (array of strings)</span></dt><dd><p>An array of arguments that will be passed to make install</p></dd><dt><span class="term"><code class="option">rm-configure</code> (boolean)</span></dt><dd><p>If true, remove the configure script before starting build</p></dd><dt><span class="term"><code class="option">no-autogen</code> (boolean)</span></dt><dd><p>Ignore the existence of an autogen script</p></dd><dt><span class="term"><code class="option">no-parallel-make</code> (boolean)</span></dt><dd><p>Don't call make with arguments to build in parallel</p></dd><dt><span class="term"><code class="option">install-rule</code> (string)</span></dt><dd><p>Name of the rule passed to make for the install phase, default is install</p></dd><dt><span class="term"><code class="option">no-make-install</code> (boolean)</span></dt><dd><p>Don't run the make install (or equivalent) stage</p></dd><dt><span class="term"><code class="option">no-python-timestamp-fix</code> (boolean)</span></dt><dd><p>Don't fix up the *.py[oc] header timestamps for ostree use.</p></dd><dt><span class="term"><code class="option">cmake</code> (boolean)</span></dt><dd><p>Use cmake instead of configure (deprecated: use buildsystem instead)</p></dd><dt><span class="term"><code class="option">buildsystem</code> (string)</span></dt><dd><p>Build system to use: autotools, cmake, cmake-ninja, meson, simple, qmake</p></dd><dt><span class="term"><code class="option">builddir</code> (boolean)</span></dt><dd><p>Use a build directory that is separate from the source directory</p></dd><dt><span class="term"><code class="option">subdir</code> (string)</span></dt><dd><p>Build inside this subdirectory of the extracted sources</p></dd><dt><span class="term"><code class="option">build-options</code> (object)</span></dt><dd><p>A build options object that can override global options</p></dd><dt><span class="term"><code class="option">build-commands</code> (array of strings)</span></dt><dd><p>An array of commands to run during build (between make and make install if those are used).
                    This is primarily useful when using the "simple" buildsystem.
                    Each command is run in <code class="literal">/bin/sh -c</code>, so it can use standard POSIX shell syntax such as piping output.
                    </p></dd><dt><span class="term"><code class="option">post-install</code> (array of strings)</span></dt><dd><p>An array of shell commands that are run after the install phase. Can for example
                    clean up the install dir, or install extra files.
                    </p></dd><dt><span class="term"><code class="option">cleanup</code> (array of strings)</span></dt><dd><p>An array of file patterns that should be removed at the end.
                    Patterns starting with / are taken to be full pathnames (without the /app prefix), otherwise they just match
                    the basename. Note that any patterns will only match files installed by this module.
                    </p></dd><dt><span class="term"><code class="option">ensure-writable</code> (array of strings)</span></dt><dd><p>The way the builder works is that files in the install directory
                    are hard-links to the cached files, so you're not allowed to modify them in-place.
                    If you list a file in this then the hardlink will be broken and you can modify it.
                    This is a workaround, ideally installing files should replace files, not modify
                    existing ones.</p></dd><dt><span class="term"><code class="option">only-arches</code> (array of strings)</span></dt><dd><p>If non-empty, only build the module on the arches listed.</p></dd><dt><span class="term"><code class="option">skip-arches</code> (array of strings)</span></dt><dd><p>Don't build on any of the arches listed.</p></dd><dt><span class="term"><code class="option">cleanup-platform</code> (array of strings)</span></dt><dd><p>Extra files to clean up in the platform.</p></dd><dt><span class="term"><code class="option">run-tests</code> (boolean)</span></dt><dd><p>If true this will run the tests after installing.</p></dd><dt><span class="term"><code class="option">test-rule</code> (string)</span></dt><dd><p>The target to build when running the tests. Defaults to "check" for make and "test" for ninja. Set to empty to disable.</p></dd><dt><span class="term"><code class="option">test-commands</code> (array of strings)</span></dt><dd><p>Array of commands to run during the tests.</p></dd><dt><span class="term"><code class="option">modules</code> (array of objects or strings)</span></dt><dd><p>An array of objects specifying nested modules to be built before this one.
                    String members in the array are interpreted as names of a separate json or yaml file that contains a module.</p></dd></dl></div></div><div class="refsect2"><a id="idp299477156"></a><h3>Sources</h3><p>
                These contain a pointer to the source that will be extracted into the source directory before
                the build starts. They can be of several types, distinguished by the type property.
            </p><p>
                Additionally, the sources list can contain a plain string, which is interpreted as the name
                of a separate json or yaml file that is read and inserted at this point. The file can contain
                a single source, or an array of sources.
            </p><div class="refsect3"><a id="idp299478116"></a><h4>All sources</h4><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="option">only-arches</code> (array of strings)</span></dt><dd><p>If non-empty, only build the module on the arches listed.</p></dd><dt><span class="term"><code class="option">skip-arches</code> (array of strings)</span></dt><dd><p>Don't build on any of the arches listed.</p></dd><dt><span class="term"><code class="option">dest</code> (string)</span></dt><dd><p>Directory inside the source dir where this source will be extracted.</p></dd></dl></div></div><div class="refsect3"><a id="idp299481268"></a><h4>Archive sources (tar, zip)</h4><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="option">type</code></span></dt><dd><p>"archive"</p></dd><dt><span class="term"><code class="option">path</code> (string)</span></dt><dd><p>The path of the archive</p></dd><dt><span class="term"><code class="option">url</code> (string)</span></dt><dd><p>The URL of a remote archive that will be downloaded. This overrides path if both are specified.</p></dd><dt><span class="term"><code class="option">mirror-urls</code> (array of strings)</span></dt><dd><p>A list of alternative urls that are used if the main url fails.</p></dd><dt><span class="term"><code class="option">git-init</code> (boolean)</span></dt><dd><p>Whether to initialise the repository as a git repository.</p></dd><dt><span class="term"><code class="option">md5</code> (string)</span></dt><dd><p>The md5 checksum of the file, verified after download</p><p>Note that md5 is no longer considered a safe checksum, we recommend you use at least sha256.</p></dd><dt><span class="term"><code class="option">sha1</code> (string)</span></dt><dd><p>The sha1 checksum of the file, verified after download</p><p>Note that sha1 is no longer considered a safe checksum, we recommend you use at least sha256.</p></dd><dt><span class="term"><code class="option">sha256</code> (string)</span></dt><dd><p>The sha256 checksum of the file, verified after download</p></dd><dt><span class="term"><code class="option">sha512</code> (string)</span></dt><dd><p>The sha512 checksum of the file, verified after download</p></dd><dt><span class="term"><code class="option">strip-components</code> (integer)</span></dt><dd><p>The number of initial pathname components to strip during extraction. Defaults to 1.</p></dd><dt><span class="term"><code class="option">dest-filename</code> (string)</span></dt><dd><p>Filename to for the downloaded file, defaults to the basename of url.</p></dd></dl></div></div><div class="refsect3"><a id="idp299491956"></a><h4>Git sources</h4><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="option">type</code></span></dt><dd><p>"git"</p></dd><dt><span class="term"><code class="option">path</code> (string)</span></dt><dd><p>The path to a local checkout of the git repository. Due to how git-clone works, this will be much faster than specifying a URL of file:///...</p></dd><dt><span class="term"><code class="option">url</code> (string)</span></dt><dd><p>URL of the git repository. This overrides path if both are specified. When using git via SSH, the correct syntax is ssh://user@domain/path/to/repo.git.</p></dd><dt><span class="term"><code class="option">branch</code> (string)</span></dt><dd><p>The branch to use from the git repository</p></dd><dt><span class="term"><code class="option">tag</code> (string)</span></dt><dd><p>The tag to use from the git repository</p></dd><dt><span class="term"><code class="option">commit</code> (string)</span></dt><dd><p>The commit to use from the git repository. If branch is also specified, then it is verified that the branch/tag is at this specific commit. This is
                        a readable way to document that you're using a particular tag, but verify that it does not change.</p></dd><dt><span class="term"><code class="option">disable-fsckobjects</code> (boolean)</span></dt><dd><p>Don't use transfer.fsckObjects=1 to mirror git repository. This may be needed for some (broken) repositories.</p></dd><dt><span class="term"><code class="option">disable-shallow-clone</code> (boolean)</span></dt><dd><p>Don't optimize by making a shallow clone when downloading the git repo.</p></dd></dl></div></div><div class="refsect3"><a id="idp299499476"></a><h4>Bzr sources</h4><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="option">type</code></span></dt><dd><p>"bzr"</p></dd><dt><span class="term"><code class="option">url</code> (string)</span></dt><dd><p>URL of the bzr repository</p></dd><dt><span class="term"><code class="option">revision</code> (string)</span></dt><dd><p>A specific revision to use in the branch</p></dd></dl></div></div><div class="refsect3"><a id="idp299502452"></a><h4>Svn sources</h4><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="option">type</code></span></dt><dd><p>"svn"</p></dd><dt><span class="term"><code class="option">url</code> (string)</span></dt><dd><p>URL of the svn repository, including branch/tag part</p></dd><dt><span class="term"><code class="option">revision</code> (string)</span></dt><dd><p>A specific revision number to use</p></dd></dl></div></div><div class="refsect3"><a id="idp299505492"></a><h4>Directory sources</h4><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="option">type</code></span></dt><dd><p>"dir"</p></dd><dt><span class="term"><code class="option">path</code> (string)</span></dt><dd><p>The path of a local directory whose content will be copied into the source dir. Note that directory sources don't currently support caching, so they will be rebuilt each time.</p></dd><dt><span class="term"><code class="option">skip</code> (array of strings)</span></dt><dd><p>Source files to ignore in the directory.</p></dd></dl></div></div><div class="refsect3"><a id="idp299508628"></a><h4>File sources</h4><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="option">type</code></span></dt><dd><p>"file"</p></dd><dt><span class="term"><code class="option">path</code> (string)</span></dt><dd><p>The path of a local file that will be copied into the source dir</p></dd><dt><span class="term"><code class="option">url</code> (string)</span></dt><dd><p>The URL of a remote file that will be downloaded and copied into the source dir. This overrides path if both are specified.</p></dd><dt><span class="term"><code class="option">mirror-urls</code> (array of strings)</span></dt><dd><p>A list of alternative urls that are used if the main url fails.</p></dd><dt><span class="term"><code class="option">md5</code> (string)</span></dt><dd><p>The md5 checksum of the file, verified after download. This is optional for local files.</p><p>Note that md5 is no longer considered a safe checksum, we recommend you use at least sha256.</p></dd><dt><span class="term"><code class="option">sha1</code> (string)</span></dt><dd><p>The sha1 checksum of the file, verified after download. This is optional for local files.</p><p>Note that sha1 is no longer considered a safe checksum, we recommend you use at least sha256.</p></dd><dt><span class="term"><code class="option">sha256</code> (string)</span></dt><dd><p>The sha256 checksum of the file, verified after download. This is optional for local files.</p></dd><dt><span class="term"><code class="option">sha512</code> (string)</span></dt><dd><p>The sha512 checksum of the file, verified after download. This is optional for local files.</p></dd><dt><span class="term"><code class="option">dest-filename</code> (string)</span></dt><dd><p>Filename to use inside the source dir, default to the basename of path.</p></dd></dl></div></div><div class="refsect3"><a id="idp299517796"></a><h4>Script sources</h4><p>
                    This is a way to create a shell (/bin/sh) script from an inline set of commands.
                </p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="option">type</code></span></dt><dd><p>"script"</p></dd><dt><span class="term"><code class="option">commands</code> (array of strings)</span></dt><dd><p>An array of shell commands that will be put in a shellscript file</p></dd><dt><span class="term"><code class="option">dest-filename</code> (string)</span></dt><dd><p>Filename to use inside the source dir, default to autogen.sh.</p></dd></dl></div></div><div class="refsect3"><a id="idp299521156"></a><h4>Shell sources</h4><p>
                    This is a way to create/modify the sources by running shell commands.
                </p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="option">type</code></span></dt><dd><p>"shell"</p></dd><dt><span class="term"><code class="option">commands</code> (array of strings)</span></dt><dd><p>An array of shell commands that will be run during source extraction</p></dd></dl></div></div><div class="refsect3"><a id="idp299523636"></a><h4>Patch sources</h4><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="option">type</code></span></dt><dd><p>"patch"</p></dd><dt><span class="term"><code class="option">path</code> (string)</span></dt><dd><p>The path of a patch file that will be applied in the source dir</p></dd><dt><span class="term"><code class="option">paths</code> (array of strings)</span></dt><dd><p>An list of paths to a patch files that will be applied in the source dir, in order</p></dd><dt><span class="term"><code class="option">strip-components</code> (integer)</span></dt><dd><p>The value of the -p argument to patch, defaults to 1.</p></dd><dt><span class="term"><code class="option">use-git</code> (boolean)</span></dt><dd><p>Whether to use "git apply" rather than "patch" to apply the patch, required when the patch file contains binary diffs.</p></dd><dt><span class="term"><code class="option">use-git-am</code> (boolean)</span></dt><dd><p>Whether to use "git am" rather than "patch" to apply the patch, required when the patch file contains binary diffs. You cannot use this at the same time as <code class="option">use-git</code>.</p></dd><dt><span class="term"><code class="option">options</code> (array of strings)</span></dt><dd><p>Extra options to pass to the patch command.</p></dd></dl></div></div><div class="refsect3"><a id="idp299530516"></a><h4>Extra data sources</h4><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="option">type</code></span></dt><dd><p>"extra-data"</p></dd><dt><span class="term"><code class="option">filename</code> (string)</span></dt><dd><p>The name to use for the downloaded extra data</p></dd><dt><span class="term"><code class="option">url</code> (string)</span></dt><dd><p>The url to the extra data.</p></dd><dt><span class="term"><code class="option">sha256</code> (string)</span></dt><dd><p>The sha256 of the extra data.</p></dd><dt><span class="term"><code class="option">size</code> (number)</span></dt><dd><p>The size of the extra data.</p></dd><dt><span class="term"><code class="option">installed-size</code> (string)</span></dt><dd><p>The extra installed size this adds to the app (optional).</p></dd></dl></div></div></div></div><div class="refsect1"><a id="idp299536148"></a><h2>Build environment</h2><p>
        When building the application each command is run in a separate sandbox with access
        to only the things required for it. This section describes the details of the sandbox.
        Any options here can be overridden globally or per-module with the <code class="option">build-args</code>
        option (although such manifest will not work if you start flatpak-builder with <code class="option">--sandbox</code>).
      </p><div class="refsect2"><a id="idp299537236"></a><h3>Filesystem</h3><p>
          Each module is built in its own build directory, stored in a sub directory called
          <code class="filename">build/$modulename-$count</code> in the state dir (which is typically <code class="filename">.flatpak-builder/</code>).
          Additionally there is a symlink <code class="filename">build/$modulename</code> to the latest version.
          In order to generate reproducible builds this directory is also mounted as <code class="filename">/run/build/$modulename</code>
          in the sandbox (or <code class="filename">/run/build-runtime/$modulename</code> when building runtimes).
          This is used as current working directory for all build ops.
        </p><p>
          The destination directory for installation is accessible for writing at the place it will seen at runtime.
          In the case of a regular application this will be /app. If building a runtime it will instead be /usr, and
          when building an extension it will be at the extensionpoint directory somewhere below /app (for app extension)
          or /usr (for runtime extensions).
        </p><p>
          Additionally the there will be (as needed, depending on what is building) read-only mounts of the sdk at /usr,
          sdk extensions below that, and the application at /app. No other filesystem access is available.
        </p></div><div class="refsect2"><a id="idp299540804"></a><h3>Environment</h3><p>
          The environment can be modified in several ways in the manifest, but the default values are:
        </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">FLATPAK_ID</span></dt><dd><p>The id of the application currently building.</p></dd><dt><span class="term">FLATPAK_ARCH</span></dt><dd><p>The architecture currently building.</p></dd><dt><span class="term">FLATPAK_DEST</span></dt><dd><p>The path to where the current build should install into. This is <code class="filename">/app</code> for application builds.</p></dd><dt><span class="term">FLATPAK_BUILDER_N_JOBS</span></dt><dd><p>The number of jobs that flatpak-builder would normally use for make -j. Defaults to ncpus unless the module disabled parallel make.</p></dd><dt><span class="term">FLATPAK_BUILDER_BUILDDIR</span></dt><dd><p>The path to the build directory of the module currently building. This is normally <code class="filename">/run/build/$MODULE</code>.</p></dd><dt><span class="term">PATH</span></dt><dd><p><code class="filename">/app/bin:/usr/bin</code></p></dd><dt><span class="term">LD_LIBRARY_PATH</span></dt><dd><p><code class="filename">/app/lib</code></p></dd><dt><span class="term">PKG_CONFIG_PATH</span></dt><dd><p><code class="filename">/app/lib/pkgconfig:/app/share/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig</code></p></dd><dt><span class="term">ACLOCAL_PATH</span></dt><dd><p><code class="filename">/app/share/aclocal</code></p></dd><dt><span class="term">C_INCLUDE_PATH</span></dt><dd><p><code class="filename">/app/include</code></p></dd><dt><span class="term">CPLUS_INCLUDE_PATH</span></dt><dd><p><code class="filename">/app/include</code></p></dd><dt><span class="term">LDFLAGS</span></dt><dd><p>-L/app/lib </p></dd><dt><span class="term">LC_ALL</span></dt><dd><p>en_US.utf8</p></dd></dl></div></div><div class="refsect2"><a id="idp302298052"></a><h3>Permissions</h3><p>
          Builds have the --allow=devel and --allow=multiarch permissions that regular flatpak runs don't have by default. This allows
          limits the syscall filtering that is normally done so development tools like debuggers work. Otherwise the build sandbox
          is very limited, for example there is no network access.
        </p></div></div><div class="refsect1"><a id="idp302299044"></a><h2>Examples</h2><p>
            <span class="command"><strong>$ flatpak-builder my-app-dir manifest.json</strong></span>
        </p><p>
            Example manifest file:
        </p><pre class="programlisting">
{
    "id": "org.test.TestApp",
    "runtime": "org.freedesktop.Platform",
    "runtime-version": "1.2",
    "sdk": "org.freedesktop.Sdk",
    "command": "test",
    "clean": [ "/include", "*.la" ],
    "build-options" : {
        "cflags": "-O2 -g",
        "cxxflags": "-O2 -g",
        "env": {
            "V": "1"
        },
        "arch": {
            "x86_64": {
                "cflags": "-O3 -g",
            }
        }
    },
    "modules": [
        {
            "name": "pygobject",
            "config-opts": [ "--disable-introspection" ],
            "sources": [
                {
                    "type": "archive",
                    "url": "http://ftp.gnome.org/pub/GNOME/sources/pygobject/2.28/pygobject-2.28.6.tar.xz",
                    "sha256": "fb8a1d4f665130a125011659bd347c7339c944232163dbb9a34fd0686577adb8"
                },
                {
                    "type": "patch",
                    "path": "required-pygobject-fix.patch"
                },
                {
                    "type": "file",
                    "path": "pygobject-extra-file",
                    "dest-filename": "extra-file"
                }
            ]
        },
        {
            "name": "babl",
            "build-options" : { "cxxflags": "-O2 -g -std=c++11" },
            "cleanup": [ "/bin" ],
            "sources": [
                {
                    "type": "git",
                    "url": "https://gitlab.gnome.org/GNOME/babl.git"
                }
            ]
        },
        {
            "name": "testapp",
            "sources": [
                {
                    "type": "bzr",
                    "url": "lp:testapp"
                }
            ]
        }
    ]
}
</pre></div><div class="refsect1"><a id="idp302302308"></a><h2>See also</h2><p>
            <a class="citerefentry" href="#flatpak-builder"><span class="citerefentry"><span class="refentrytitle">flatpak-builder</span>(1)</span></a>
        </p></div></div></div></div></body></html>