Meson does not support builddir == srcdir, so there is no reason to
require developers to set "builddir" to true in their manifests, when we
can just do the right thing.
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.
In the case of the source-file we have code that handle
the file inline. When we extract the source we do set
the url with that inline data. In get_download_location
that is also used by the bundling code we do then
check against this url and fail.
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.
This is useful for modules that don't have a make install rule.
You can use the new build-commands which is run after make to
create your own custom installation phase.
Fixes https://github.com/flatpak/flatpak/issues/458
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.
It can happen, like in https://github.com/flatpak/flatpak/issues/353
that there are references in the source to the absolute source path.
We need to ensure that is visible in the build. We mostly do this,
but for technical reasons it didn't get the same pathname when
the source was inside a symlinked directory. We fix this with an
extra bind-mount to the symlinked directory name too.
This fixes https://github.com/flatpak/flatpak/issues/353
This way you can e.g. do network i/o in them.
Thats not a recommended way to do it though, as you work around
a lot of the feature in flatpak-builder like the caching and
verification.
This disables build-args support, which is nice when building things
on e.g. a shared build-machine, where we don't want the build to
be able to break out of the sandbox (by specifying e.g. --share=network).
This replaces all current callers of gs_file_ensure_directory with
equivalent code.
Actually, two instances were calling gs_file_ensure_directory with
FALSE, i.e. error out on EEXIST, but those cases seem fine with the
do-nothing-if-exists semantics.
We were not doing what the comments said we should, and we also
want to change what happens in the case of an old py file from
a previous layer (such as a base layer in a runtime) has a non-rewritten
.pyc file. In that case we want to assume its correct and fix it up.
