This takes a list of properties and generate finish arguments.
Additionally you can specify "bundle": true, which causes f-b to emit
an actual extension implementation, similar to e.g. the locale
and debuginfo extension.
This makes sure we always delete build dirs, even if there
was a build failure. This is useful for automatic build systems
like flathub or continuous integration.
This fixes https://github.com/flatpak/flatpak/issues/646
Pass a --collection-id argument through to `flatpak build-export`.
Also add a ‘collection-id’ property to manifest files, which can be used
to set the collection ID on an exported repo (when using --repo) without
having to provide a command line option.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This allows you to automatically install/update dependencies required
by the manifest. The dependencies include:
Runtime, Sdk, Base, Sdk Extensions and Platform Extensions
There is also a --install-deps-only switch to make the build
stop after the dependencies are installed.
Fixes https://github.com/flatpak/flatpak/issues/955
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 prevents a resource leak, although not really in practice because
va_args are free on common platforms.
Coverity issue 1452430.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
flatpak-builder was running into an assertion when --run was
used after a non-option. Catch this and exit with a clear error
message. Same for --show-deps
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>
This makes it easier to avoid typos, and also makes it easier to see
what groups and keys are in use. In the header file, they are
clustered according to the group in which the keys are used.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If isatty(STDOUT_FILE) is true, then we can possibly send
escape sequences to set the title of the terminal. This is
useful for both terminals like gnome-terminal as well as
programs scripting flatpak-builder such as Builder. This allows
those programs to get information about the current build
progress without having to parse the command line output which
is muxed with build information.
For example, add $(AM_CFLAGS) to mumble_CFLAGS. Since $(WARN_CFLAGS) is
only added to $(AM_CFLAGS), this fixes the lack of inclusion of the
compiler warning flags in the compilation of half of flatpak.
Note that $(AM_*) variables are only used by automake if a more specific
(per-target) special variable is not defined instead. So if you define
mumble_CFLAGS, AM_CFLAGS will not be used for that target unless
explicitly included in mumble_CFLAGS.
See
https://www.gnu.org/software/automake/manual/html_node/Flag-Variables-Ordering.html.
Do the same for $(AM_LIBADD), $(AM_LDFLAGS), etc. These are not
currently defined, but it’s good practice to include them in
mumble_LIBADD (etc.) just in case they’re defined in future. Hopefully
their inclusions will be cargo-culted to any new targets which are
added, retaining full coverage of the code base.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
All the similarly named functions were in the header file, but this one
was left out. Stop it feeling sad and lonely by putting it in the header
file with its friends.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The compiler warning flag which was supposed to warn about this was not
being included in the CFLAGS for these targets. That will be fixed in an
upcoming commit.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Previously, the mandatory location, directory and branch positional
arguments were passed as part of the varargs. This meant the varargs
were conflating flags and positional arguments, making it harder to add
new positional arguments.
Move the mandatory positional arguments to separate parameters for
do_export(). This introduces no functional changes, but makes later
commits easier.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
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.
They were being set to an uninitialised set of flags from cxxflags.
Spotted as a compiler warning.
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.
Specify --mirror-screenshots-url=URL and then copy the resulting
appdata/screenshots directory to the URL, then these
will be used instead of the upstream screenshots.
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.
Alexander Larsson