Add --dependency-file=foo.d option to generate a gcc -M -MF style
dependency file for other build tools. The current output of
--generate-dependencies is only useful for use directly in Makefile
rules, but can't be used in other build systems like that.
The generated dependency file looks like this:
$ glib-compile-resources --sourcedir= test.gresource.xml --dependency-file=-
test.gresource.xml: test1.txt test2.txt test2.txt
test1.txt:
test2.txt:
test2.txt:
Unlike --generate-dependencies, the --dependency-file option can be
used together with other --generate options to create dependencies
as side-effect of generating sources.
Based on a patch by Tim-Philipp Müller in
https://bugzilla.gnome.org/show_bug.cgi?id=745754
The changes in this patch, compared to his are to always return
the hash table with file information from parse_resource_file, so
we can use it for dependency output, regardless if generate_dependencies
was TRUE or not.
Add --dependency-file=foo.d option to generate a gcc -M -MF style
dependency file for other build tools. The current output of
--generate-dependencies is only useful for use directly in Makefile
rules, but can't be used in other build systems like that.
The generated dependency file looks like this:
$ glib-compile-resources --sourcedir= test.gresource.xml --dependency-file=-
test.gresource.xml: test1.txt test2.txt test2.txt
test1.txt:
test2.txt:
test2.txt:
Unlike --generate-dependencies, the --dependency-file option can be
used together with other --generate options to create dependencies
as side-effect of generating sources.
Based on a patch by Tim-Philipp Müller.
https://bugzilla.gnome.org/show_bug.cgi?id=745754
Previously, this would not work, as it would result in comparing the
order of a string and an integer. Make it work, and make 'UNRELEASED'
compare higher than other versions so it's always treated as the latest
version.
'UNRELEASED' is commonly used by maintainers to highlight new API while
it's being prototyped, until they know which version it will actually
be released in. At the time of release, they replace all 'UNRELEASED'
strings in git with the new version number.
An example of this usage is here:
d380ac6a2a (9208ee267cb05db1afd3a5c323d71e51db489447_7619_7656)https://bugzilla.gnome.org/show_bug.cgi?id=769995
Circa 8.38, upstream PCRE (intentionally?) changed behaviour with
respect to whether options set with expressions like "(?i)" at the
top-level were reported via the pcre_fullinfo() API as having been
requested during compilation.
GLib contained a test that verified that these options were indeed
reported as if they had been provided as flags on the API.
Remove that check, and document the no-longer-deterministic behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=767240
gcc 6 warns (fatally, by default) that %c only uses a 2-digit year
in some locales. The precise format does not seem to be important
for this sample code, so use ISO 8601 instead of suppressing the
warning with a pragma.
Signed-off-by: Simon McVittie <smcv@debian.org>
Reviewed-by: Colin Walters
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=768453
I realise this is a contradiction in terms, but it keeps code analysis
tools happy. As spotted by cppcheck, which could not attend GUADEC, but
sends everyone its best wishes anyway.
This should not change the behaviour of the test, unless the test's
behaviour is changed in future. As spotted by cppcheck, which has
impeccable taste and a flair for the unexpected.
At some point, upstream SystemTap changed from using a
STAP_HAS_SEMAPHORES preprocessor variable for this, to using
_SDT_HAS_SEMAPHORES instead. We need to update our build system to
disable that as well.
The original discussion about use of semaphores is here:
https://bugzilla.gnome.org/show_bug.cgi?id=606044
This was breaking the build with -flto enabled, either because -flto
doesn’t work with semaphores.
https://bugzilla.gnome.org/show_bug.cgi?id=768198
Ensure that all the old log handler documentation includes
cross-references to a new section about how to enable structured logging
(tl;dr: #define G_LOG_USE_STRUCTURED).
https://bugzilla.gnome.org/show_bug.cgi?id=769785
Give some example log domains, and recommend that G_MESSAGES_DEBUG is
used universally as the way to enable debug output (rather than having a
separate environment variable per library).
https://bugzilla.gnome.org/show_bug.cgi?id=682794
It’s effectively deprecated if G_LOG_USE_STRUCTURED is defined, or if
the structured logging API is used directly. See the documentation for
rationale.
https://bugzilla.gnome.org/show_bug.cgi?id=769486
g_log_writer_is_journald() works out whether the process’ stderr or
stdout are redirected to journald. While the default writer function
uses this in conjunction with g_log_writer_journald(), that does not
always have to be the case — other writer functions might want to always
write to the journal, and never write to stderr (for example).
Consequently, automatically open the journal socket in
writer_journald(), rather than is_journald().
https://bugzilla.gnome.org/show_bug.cgi?id=769507
The C spec leaves conditional evaluation inside a macro expansion as
undefined behaviour. This means we cannot use constructs like:
GOBJECT_IF_DEBUG(OBJECTS, {
...
#ifdef BLAH
...
#endif
...});
Because compilers are entirely justified to ignore the conditional, or,
like in the case of MSVC, error out.
https://bugzilla.gnome.org/show_bug.cgi?id=769504
GDatagramBased allows connection-oriented and connection-less sockets,
but does not allow stream-based sockets (because it’s datagram-based).
So it supports SCTP and UDP, but not TCP.
Clarify that in the documentation, and people sometimes confuse
connection-oriented with stream-based, due to the prevalence of TCP.
This is causing trouble with flatpaks because the org.gnome.Platform
runtime does not bundle libmount, while the org.gnome.Sdk does it.
As this probably requires a change in the freedesktop.org Yocto base,
we disable this support by default for now as a temporary measure
until it can be properly reviewed by someone who knows those bits
better, probably Alex Larsson.
https://bugzilla.gnome.org/show_bug.cgi?id=769284
