It uses inline for loop initialisers, which are a C99 feature. Set
-std=gnu99 like ostree.git does for its libglnx submodule.
Based on a patch by Georges Basile Stavracas Neto
<georges.stavracas@gmail.com>.
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
We were checking the prefix twice here, instead of
checking prefix and suffix, which was obviously the
intention.
This caused extensions with non-matching architectures
to be reported as related refs.
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>
Use g_hash_table_add() so that GHashTable can internally optimise for
use as a set, which results in slightly simpler code for the caller, and
slightly less memory usage overall.
This introduces no functional changes.
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>
Clang otherwise complains about the printf() format string not being a
string literal, which is a bit pants.
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>
This introduces no functional changes. The split out function will be
reused in a later commit to additionally load commit data from the
ostree-metadata branch.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This will slightly simplify some later refactoring. It makes no real
difference to the function’s behaviour at the moment.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This was accidentally introduced in a8ad3927 in advance of the LAN/USB
changes from PR #884 which will actually use it.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The library test previously used the real ~/.cache, while the
library test and the shell-script tests would use the real ~/.config
to look up the XDG user-dirs.dirs. Other home-directory-related code
might have used the real $HOME.
As a general rule, build-time tests should not affect the real home
directory. Debian autobuilders run as a user whose home directory
does not exist, in order to catch packages whose build process could
affect or be affected by the contents of the home directory. This
caused testlibrary to fail when it tried to create that nonexistent
directory, which I think happened while trying to create ~/.cache.
Signed-off-by: Simon McVittie <smcv@debian.org>
Changes to the Makefile could include changes to the options passed
to gdbus-codegen, which would invalidate the output.
Signed-off-by: Simon McVittie <smcv@collabora.com>
A rule of the form
foo.c foo.h: foo.in
some-generator --output=foo foo.in
is essentially equivalent to writing the same rule once for each target:
foo.c: foo.in
some-generator --output=foo foo.in
foo.h: foo.in
some-generator --output=foo foo.in
In a parallel build, this can result in some-generator being run more
than once with the same inputs and outputs, leading to unpredictable
results if the outputs are overwritten in-place by two parallel copies
(particularly if the generator does not use the standard atomic-writing
trick of writing out a temporary file and renaming it over the top of
the intended name, which gdbus-codegen does not).
gdbus-codegen happens to write the .h file before the .c file, so
use the real build rules to generate the .c file, and consider the
.h file to be a side-effect.
Signed-off-by: Simon McVittie <smcv@collabora.com>
