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).
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.
If the ref specified in "branch" is actually a tag, we were requiring
that the "commit" property must match "git rev-parse $branch", but
in the case of a tagname that actually expands to the id of the
tag object, not the commit id. We now also try to match against
"rev-parse $branch^{commit}" which expands to the actual commit
object.
We still allow the tag object for backwards compat.
Rather than just prepending _tmp this creates a unique
directory name, which means we don't run into issues
when retrying if the first checkout fails.
Fixes https://github.com/flatpak/flatpak/issues/786
The new `glnx_regfile_copy_bytes()` is better than the previous
`flatpak_copy_bytes()` in that it will use reflink/sendfile if available.
More information in 3a4d0f4684
Never check out directly from the cached dir, instead always
create a .flatpak-builder/bzr/ directory we can later
update from by branching from the cache and then rewriting
the parent location.
We always have a local git checkout in .flatpak-builder/git
so that we can later update in it. However, if --extra-sources
is used and the git repo exists there, we use the data there
to clone the initial repo, to avoid lots of traffic on the network.
Additionally, if --disable-update is specified we just straight
clone the local cache repo, and then rewrite the origin to the
real one. This means we never do any network i/o to the original
pull.
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.
