Any build-args specified in the manifest should be used during the
cleanup and platform-cleanup stages. This is because if you are using
QEMU to build for another architecture, for example, you need to pass
--bind-mount in the build-args, and the bind mount also needs to be
present while running cleanup commands.
If you inherit an extension, and it has no explicit version, then
use the version of the parent, as that is what would automatically
be used for the parent.
Instead of constantly looking at the option we change the
manifest value if its unset. This means we can access the
default branch outside of builder-main.c, and that we get
it into the serialized manifest in the build.
We have some extra conditions here that are not evident
from the rename-icon key in the manifest, so add some
verbose output to make it easier to figure out why an
icon is not renamed.
Instead of mixing the source bundling with the build we make
it a separate step at the end, with cache support just like the
other stages.
Being at the end means we can reuse the cached stages from the
build if we enable bundle-sources after an existing build.
Also, this changes how the json and local files/patches are stored.
Now they are in a subdirectory called "manifest" in the sources
directory, with proper handling of relative pathnames for included
modules, etc. This also means we don't look for these file in the
extra-sources directory, but rather next to the json like we
do normally.
This adds a step to the build process to bundle
the module sources, used for building the flatpak,
as a runtime extension.
The sources can then be installed like the
debug or translation runtime.
This also adds an option to flatpak-builder
for specifying sources directories. One can specify
source dirctories with the use-sources argument. This
will skip the download part of the processing
and will extract the sources from the given sources
directory directly for further processing.
Those source directories do need the same
structure as the ones that flatpak-builder
creates during processing in .flatpak-builder
and which is also used in the exported sources
runtime.
We're doing a post-commit checkout directly to the app dir, which
means the fuse filesystem cache may get out of sync with the backing
directory. So, to ensure this doesn't happen we mount a fresh rofiles
fs for each build.
This changes what files we look at to only those in this module,
which is generally right, but to handle the base-layer sdk
case we also have to run the python fixup in the initial layer.
If the target is the rofiles-fuse and a file is hardlinked, then
copy will fall back to truncation, which will fail with READONLY.
We work around this sometimes by deleting the destination first
and sometimes by using g_file_set_contents instead.
Instead of building directly into the app directory we build into a
rofiles-fuse mount of it, which allows us to safely check out the
cache into the app directory using hardlinks (because rofiles-fuse
will not let you modify hardlinked files).
Additionally, every time we commit to the cache we check out all
the new and modified files into the appdir so that we get hardlinks
to the repo for the new files too.
The advantage of having hardlinks to the repo is that we can commit
much more efficient since we don't have to do a full checksum of
the hardlinked files.
There are some issues here:
eu-strip fails due to doing in-place editin
rofiles-fuse is using lots of CPU, unclear if this is faster, needs
measurements
needs testing of how well the fallback works (ie. if fuse is not
working).
rofuse: use kernel caches
rofiles: check out after commit
Use devino cache
Only check out new files from cache after commit
Rebuilding all apps because a minor change in the runtime is way too wasteful
and generated unnecessary app updates, especially since runtimes are supposed
to be API stable.
We add an a --rebuild-on-sdk-change option which you use to disable this feature,
for instance if you're building against an unstable SDK.
Currently flatpak-builder downloads the sources for all modules, even if
the --stop-at option prevents them from being built. This commit changes
the behavior so that we don't bother to download the ignored modules.
An app id like org.domain.App-name is now allowed (dashes in the
last element), but blindly appending e.g. ".Locale" to these
for the locale extension will cause an invalid id.
In order to handle this we replace "-" with "_" in this case, which
should be fine as both are under the org.domain control which can
make sure there are no conflicts, and there is no requirement for
the id prefixes to exactly match.
This fixes https://github.com/flatpak/flatpak/issues/370
When initializing a build you can initialize the application directory
with the files from another directory, and optionally a set of its
extensions. This allows one to create a "base" application that
can be derived from in multiple forms. A typical example is an application
framework like Electron. The base electron app has all the dependencies
needed to write Electron app, and then your manifest can add the specific
files needed for your application.
An example snipped could look something like:
"base": "org.base.App",
"base-version": "stable",
"base-extensions": ["org.base.app.Locale", "org.base.app.Debug" ],
Philip Chimento