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.
If a .py file changes multiple times we can end up in a situation
where there is an .py file with corresponding .pyc file that we
rewrote, so both are now mtime==1. Then a new version of the .py file
is added, but the corresponding .pyc file is not updated. This means
that the .pyc file is stale, and python would not normally use it.
However, we will later change the mtime on the .py file to 1, causing
the old .pyo file to look up-to-date even though its stale.
We fix this by detecting the case where the is a new mtime on a .py file
where the .pyc file doesn't match, and remove the stale .pyc file.
This commit makes flatpak print a debug message (which only appears to
the user if the -v option is used) whenever a subprocess is launched.
This should make debugging easier, both for flatpak users and
developers.
Sprinkle g_prefix_error calls in builder-module.c, to make
sure that module-specific errors get a "module foo:" prefix.
This is not quite perfect, since callers tend to impose their
own prefix as well, but at least it clearly identifies the
module in which the error ocurred.
Putting spaces or slashes in module names is a recipe for
cryptic error from one of the many constructed flatpak
commandlines. Better warn early on, as soon as we see such
a name.
