use_builddir is TRUE if meson is TRUE, so there can never be a meson
case in the !use_builddir case.
Coverity issue: 1452428
Signed-off-by: Philip Withnall <withnall@endlessm.com>
If realpath() fails (unlikely) it returns NULL, which we later merrily
dereference. Fix that by taking the unexpanded path.
Also fix a minor indentation problem later on.
Coverity issue 1452435.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This tries to be similar to jhbuild in that we update the
terminal title at various stages of the build process.
This is useful for casual command line users. It is also useful
for applications automating the use of flatpak-builder as then
can display progress to the user without having to parse all
stdout content.
For build systems that support progress (such as ninja), this
allows for both a build message (the term title) and progress
bars (generated from %d/%d build system output).
The GLib logging framework automatically appends a \n to messages, so it
doesn’t need to be added by callers.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
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).
Philip Withnall