A commonly used CI workflow [1] is to chain the following steps:
> flatpak-builder --stop-at=<module>
> flatpak build <commands to build module from local checkout>
> flatpak-builder --finish-only
Unfortunately, the last step always purge all the compilation cache
created by the first one. All build steps are marked unused by default
and since they are skipped due to the option --finish-only, all of them
are always pruned by the gc function.
As a result, flatpak-builder cache becomes useless, a full compilation
is always performed.
Improve this by not cleaning unused stages when no compilation is done
by flatpak-builder (i.e: when flatpak-builder is used with --export-only
or --finish-only option).
[1]: https://gitlab.gnome.org/GNOME/Initiatives/wikis/DevOps-with-Flatpak
As reported in
https://bugzilla.gnome.org/show_bug.cgi?id=796031#c1
we sometimes hang in libsoup downloading stuff. This uses
an early type initialization to avoid that.
We don't use libsoup for the main download anymore, but
its still used for some things, so better safe than sorry.
Closes: #153
Approved by: alexlarsson
This is a more generic way than sdk-default-override to change how the various
flag fields are overridden. Now you can override both the sdk default as well as
in-file options.
Closes: #150
Approved by: alexlarsson
When downloading only we will not be building, so we can skip all the checks for dependencies
and for the state-dir properties.
Closes: #145
Approved by: alexlarsson
This adds a source type that copies an entire directory, optionally skipping
some files. Additionally it also skips the .flatpak-directory dir and
the build dir to avoid weird recursion.
Since we can't really checksum an entire directory a dir source is always
rebuilt.
Closes: #136
Approved by: alexlarsson
This adds add-build-extensions which is similar to add-extensions
except the extension is added at build-init time, so can be
used during the build. It can also optionally be removed after
the build is done.
This depends on the flatpak work in:
https://github.com/flatpak/flatpak/pull/1598
With this I was able to build the following app which runs 32bit binaries
in a 64bit build:
```
{
"app-id": "org.example.Multilib",
"runtime": "org.freedesktop.Platform",
"sdk": "org.freedesktop.Sdk",
"runtime-version": "1.6",
"command": "/usr/bin/true",
"add-build-extensions": {
"org.freedesktop.Platform.Compat32": {
"directory": "lib/32bit",
"add-ld-path": "lib",
"version": "1.6"
}
},
"modules": [
{
"name": "test 32bit",
"buildsystem": "simple",
"build-commands": [
"ln -s /app/lib/32bit/lib/ld-linux.so.2 /app/lib/ld-linux.so.2",
"/app/lib/32bit/bin/echo echoing from 32bit world"
]
}
]
}
```
Closes: #129
Approved by: alexlarsson
This adds a section to the main metadata like:
```
[Build]
built-extension=org.the.App.Locale;
```
This can be used to figure out what refs where built that are
related to the app, for example if you want to bundle them all.
Closes: #128
Approved by: alexlarsson
This passes an --extension-tag to flatpak build-init which will
set the "tag" option on the ExtensionOf section in the metadata.
Closes: #126
Approved by: alexlarsson
This isn't really right, as install doesn't handle an empty subpath
like that. In fact, doing so will break exports.
Closes: #124
Approved by: alexlarsson
Alexander Larsson