Commit Graph

433 Commits

Author SHA1 Message Date
Xavier Claessens
f6edb52bda Merge branch 'wip/3v1n0/some-meson-fixmes' into 'main'
meson: Handle various build system FIXME's

See merge request GNOME/glib!3012
2022-11-01 23:36:04 +00:00
Philip Withnall
cbf17c9422 Merge branch 'wip/3v1n0/support-can-fail-tests' into 'main'
meson, ci: Support tests that can fail under certain conditions

See merge request GNOME/glib!2987
2022-10-31 14:28:02 +00:00
Marco Trevisan (Treviño)
832dd0805a meson: Add basic summary
It can nicely provide information about how glib is configured
2022-10-31 14:08:31 +01:00
Marco Trevisan (Treviño)
9e649debbe meson: Use default test multiplier to define timeouts
So that we don't have to care about the default, being always set to 1m
2022-10-31 14:08:31 +01:00
Marco Trevisan (Treviño)
3c56d661d8 meson: Use test setup environment instead of repeating it everywhere 2022-10-31 14:08:31 +01:00
Marco Trevisan (Treviño)
b9e085537d meson: Expose library build type as global variables
Given that it can be computed using an error-prone strings comparisons it
is better to provide a variable everywhere, so that we don't have the
risk of comparing values that are always false.
2022-10-31 14:08:31 +01:00
Marco Trevisan (Treviño)
62dca6c1cf meson, ci: Support tests that can fail under certain conditions
We have tests that are failing in some environments, but it's
difficult to handle them because:
 - for some environments we just allow all the tests to fail: DANGEROUS
 - when we don't allow failures we have flacky tests: A CI pain

So, to avoid this and ensure that:
 - New failing tests are tracked in all platforms
 - gitlab integration on tests reports is working
 - coverage is reported also for failing tests

Add support for `can_fail` keyword on tests that would mark the test as
part of the `failing` test suite.
Not adding the suite directly when defining the tests as this is
definitely simpler and allows to define conditions more clearly (see next
commits).

Now, add a default test setup that does not run the failing and flaky tests
by default (not to bother distributors with testing well-known issues) and
eventually run all the tests in CI:
 - Non-flaky tests cannot fail in all platforms
 - Failing and Flaky tests can fail

In both cases we save the test reports so that gitlab integration is
preserved.
2022-10-31 14:08:29 +01:00
Marco Trevisan (Treviño)
69f7aa5747 meson: Ignore -Wstring-plus-int in C
It's not really a problem for us, it would be only in c++.
2022-10-31 12:02:57 +01:00
Simon McVittie
b8f37a543c glib: Always implement G_VA_COPY as va_copy()
C99 guarantees that va_copy() exists, so use it, instead of probing
for __va_copy(), va_copy(), or a reimplementation from first principles.

Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-10-26 18:07:55 +01:00
Marco Trevisan (Treviño)
bd2cb39073 meson: Remove stpcpy() workaround for old meson versions and windows
This is now supported by the meson version we depend on.
2022-10-26 17:39:25 +02:00
Marco Trevisan (Treviño)
98059d088f gmodule/meson: Use stdout to communicate return value pf dlsym test code 2022-10-26 17:39:25 +02:00
Marco Trevisan (Treviño)
4a33e2a176 meson: Undefine STAP_HAS_SEMAPHORES and _STD_HAS_SEMAPHORES as autotools did 2022-10-26 17:39:25 +02:00
Marco Trevisan (Treviño)
6dd222e753 meson: Cleanup include-dir paths, use base path without repetitions
Avoid setting the subdir all the times, just use the global definition
plus the specific module subdir
2022-10-24 21:09:09 +02:00
Philip Withnall
2365452d6e Merge branch 'allow-mixed-declarations' into 'main'
meson: Don't explicitly disable mixed declarations and statements

See merge request GNOME/glib!2951
2022-10-20 14:32:23 +00:00
Marco Trevisan (Treviño)
e85635daa0 meson: Define G_OS_DARWIN when compiling under OSX or iOS
It has enough differences to expose it as an unix-subtype.
2022-10-20 03:37:03 +02:00
Philip Withnall
4bc284fca6 Merge branch 'wip/smcv/deprecated-prop-followup' into 'main'
Run tests with G_ENABLE_DIAGNOSTIC=1

See merge request GNOME/glib!2889
2022-10-15 21:31:29 +00:00
Philip Withnall
870fc6763e Merge branch 'mcatanzaro/plain-build-cast-checks' into 'main'
Disable cast checks in plain builds

See merge request GNOME/glib!2894
2022-10-14 15:34:22 +00:00
Michael Catanzaro
631e99667e Disable cast checks in plain builds 2022-10-14 15:34:22 +00:00
Philip Withnall
192794c6a8 build: Post-release version bump to 2.75.0
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-10-14 15:20:45 +01:00
Xavier Claessens
dcfc9f689e Fix symbol visibility macros on Windows
There is currently no `dllimport` attribute on any of our function,
which prevents MSVC to optimize function calls.

To fix that issue, we need to redeclare all our visibility macros for
each of our libraries, because when compiling e.g. GIO code, we need
dllimport in GLIB headers and dllexport in GIO headers. That means they
cannot use the same GLIB_AVAILABLE_* macro.

Since that's a lot of boilerplate to copy/paste after each version bump,
this MR generate all those macros using a python script.

Also simplify the meson side by using `gnu_symbol_visibility : 'hidden'`
keyword argument instead of passing the cflag manually.

This leaves only API index to add manually into glib-docs.xml when
bumping GLib version. That file cannot be generated because Meson does
not allow passing a buit file to gnome.gtkdoc()'s main_xml kwarg
unfortunately.
2022-10-13 20:53:56 -04:00
Xavier Claessens
d40459c280 Simplify G_HAVE_GNUC_VISIBILITY definition
There is no need of compiler checks, GNUC visibility should be used when
__GNUC__ >= 4 but not on Windows.
2022-10-13 20:52:49 -04:00
Nirbheek Chauhan
aa757cd54a meson: Don't explicitly disable mixed declarations and statements
We require C99 now, and this warning was added for strict adherence to
C89 because GCC allowed mixed declarations in gnu89 as a GCC
extension. Let's get rid of this.
2022-10-14 04:56:46 +05:30
Philip Withnall
e90733a457 Merge branch 'atomic-older-cplusplus' into 'main'
gatomic: fix the atomic compare_and_exchange macros on older C++ standard versions

See merge request GNOME/glib!2864
2022-10-12 09:56:19 +00:00
Georges Basile Stavracas Neto
255fa26b96 build: Let Meson figure out Python installation
Commit 4a4d9eb662 initially switched Meson to find the python
program using find_program('python3'). Sadly that caused a
regression, since in some cases with MSVC it would fallback to
'meson.exe runpython', which is undesired.

However, that particular code was reverted back to an also
undesired lookup method, find_installation('python3'). This
way of finding python also breaks on Windows + MSVC, in particular
when setting it up as follows:

```
winget install python
winget install meson
```

This fails building GLib with:

> python3 not found

Fix that by not passing any argument to find_installation(), which
lets Meson figure it all out by itself.
2022-09-29 17:18:10 -03:00
Simon McVittie
831f5c5c2d tests: Run all tests with deprecated property warnings enabled
The tests that functionally rely on G_ENABLE_DIAGNOSTIC=1 still set it
explicitly, so that they will behave as expected when run as
installed-tests or manually.

Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-09-21 11:20:34 +01:00
Simon McVittie
88e160dfe4 tests: Move common test environment variables to top level
Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-09-21 11:19:28 +01:00
Xavier Claessens
a73ca336aa meson: Set install_tag on remaining installed files 2022-09-20 11:30:12 -04:00
Emmanuele Bassi
115d8b48ac Post-release version bump to 2.74.1 2022-09-17 19:50:37 +01:00
Marco Trevisan (Treviño)
30bd57ecf8
2.74.0
Signed-off-by: Marco Trevisan (Treviño) <mail@3v1n0.net>
2022-09-17 20:38:17 +02:00
Marco Trevisan (Treviño)
1cbe7a6734 meson: Build C++ tests for the currently supported C++ standard versions
We've various macros definitions that are depending using C++ features
that may not work in all the standard versions, so recompile the cxx
tests that we have in all the ones we want to support.
2022-09-15 01:18:40 +02:00
Marco Trevisan (Treviño)
1edb3c515a
2.73.3
Co-authored-by: Matthias Clasen <mclasen@redhat.com>
Signed-off-by: Marco Trevisan (Treviño) <mail@3v1n0.net>
2022-08-05 18:24:47 -04:00
Michael Catanzaro
61a843564d Improve default value of glib_debug option
glib_debug is an auto option. This is clever because it allows us to
guess the best default based on the build type, while also allowing an
easy way to override if the guess is not good. Sadly, the attempt to
guess based on the build type does not work well. For example, it
considers debugoptimized builds to be debug builds, but despite the
name, it is definitely a release build type (except on Windows, which
we'll ignore here). The minsize build type has the exact same problem.
The debug option is true for both build types, but this only controls
whether debuginfo is enabled, not whether debug extras are enabled.

The plain build type has a different problem: debug is off, but the
optimization option is off too, even though plain builds are distro
builds are will almost always use optimization.

I've outlined an argument for why we should make these changes here:
https://blogs.gnome.org/mcatanzaro/2022/07/15/best-practices-for-build-options/

Specifically, Rule 4 shows all the build types and whether they
correspond to release builds or debug builds. Rule 6 argues that we
should provide good defaults for plain builds.
2022-08-03 17:07:13 -05:00
Simon McVittie
ae15c800ce Install gio-launch-desktop in a non-PATH location
This is an internal helper executable, which users shouldn't invoke
directly (see glib#1633).

When building for a single-architecture distribution, we can install
it as ${libexecdir}/gio-launch-desktop.

When building for a multiarch distribution, installing it into an
architecture-specific location and packaging it alongside the GLib
library avoids the problem discussed in glib#1633 where it would either
cause a circular dependency between the GLib library and a common
cross-architecture package (libglib2.0-bin in Debian), or require a
separate package just to contain gio-launch-desktop, or cause different
architectures' copies to overwrite each other.

Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-07-25 01:00:53 +02:00
Simon McVittie
0c087d121f gio: Optionally install trigger executables to architecture-specific paths
In Debian-style multiarch (libdir = lib/x86_64-linux-gnu or similar),
Red-Hat-style multilib (libdir = lib64 or lib) and Arch-style multilib
(libdir = lib or lib32), we have to run a separate version of
gio-querymodules to discover 32- or 64-bit modules on x86. Installing
modules in the directory used for each word size needs to trigger
recompilation of the correct modules list.

Debian, Fedora and Arch currently all have patches to facilitate this:
Debian moves gio-querymodules into ${libdir}/glib-2.0 and provides a
compat symlink in ${bindir}, while Fedora and Arch rename one or both
of the gio-querymodules executables to give it a -32 or -64 suffix.

We can avoid the need for these patches by making this a build option.
Doing this upstream has the advantage that the pkg-config metadata for
each architecture points to the correct executable and is in sync with
reality.

I'm using Debian's installation scheme with a separate directory here,
because the word-size suffix used in Fedora and Arch only works for the
common case of 32- and 64-bit multilib, and does not cover scenarios
where there can be more than one ABI with the same word size, such as
multiarch cross-compilation or alternative ABIs like x32.

Now that we have this infrastructure, it's also convenient to use it for
glib-compile-schemas. This works with /usr/share, so it only needs to
be run for one architecture (typically the system's primary
architecture), but using /usr/bin/glib-compile-schemas for the trigger
would result in either primary and secondary architectures trying to
overwrite each other's /usr/bin/glib-compile-schemas binaries, or a
circular dependency (the GLib library would have to depend on a
common package that contains glib-compile-schemas, but
glib-compile-schemas depends on the GLib library). Installing a
glib-compile-schemas binary in an architecture-specific location
alongside each GLib library bypasses this problem.

Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-07-24 11:19:37 +01:00
James Hilliard
d0b9ebbaac meson: fix build without cpp toolchain
We don't need a cpp toolchain for building glib so lets just
automatically disable tests requiring one when not available.

Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
2022-07-15 12:58:41 -06:00
Marco Trevisan (Treviño)
f622a4ed53
2.73.2
Co-authored-by: Matthias Clasen <mclasen@redhat.com>
Signed-off-by: Marco Trevisan (Treviño) <marco@ubuntu.com>
2022-07-12 18:32:22 +02:00
Philip Withnall
4353813058 build: Specify -Werror=pointer-sign
This can catch the wrong pointer being passed to a function argument (in
some cases), with few false positives.

Spotted while testing !2529.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-07-12 15:55:59 +02:00
Aleksei Rybalkin
8d5a44dc8f replace pcre1 with pcre2 2022-07-12 11:46:34 +00:00
Philip Withnall
f615eef4ba gmain: Use waitid() on pidfds rather than a global SIGCHLD handler
When the system supports it (as all Linux kernels ≥ 5.3 should), it’s
preferable to use `pidfd_open()` and `waitid()` to be notified of
child processes exiting or being signalled, rather than installing a
default `SIGCHLD` handler.

A default `SIGCHLD` handler is global, and can never interact well with
other code (from the application or other libraries) which also wants to
install a `SIGCHLD` handler.

This use of `pidfd_open()` is racy (the PID may be reused between
`g_child_watch_source_new()` being called and `pidfd_open()` being
called), so it doesn’t improve behaviour there. For that, we’d need
continuous use of pidfds throughout GLib, from fork/spawn time until
here. See #1866 for that.

The use of `waitid()` to get the process exit status could be expanded
in future to also work for stopped or continued processes (as per #175)
by adding `WSTOPPED | WCONTINUED` into the flags. That’s a behaviour
change which is outside the strict scope of adding pidfd support,
though.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Helps: #1866
Fixes: #2216
2022-07-07 14:08:29 +01:00
Marco Trevisan (Treviño)
b61cd872f1 build: Threat unused-result warnings as errors
We don't have any in code now, so we should definitely ensure that we
won't introduce anymore unguarded calls.
2022-07-06 18:41:10 +02:00
Emmanuele Bassi
2a12de5b1d Require C99's __VA_ARGS__
We have fallback in places for GNU's variadic arguments in macros, and
for static inline functions with variadic arguments as an fallback of
last resort, but going forward we are going to depend on `__VA_ARGS__`
for macros that cannot be re-implemented using a static inline function.

Fixes: #2681
2022-06-30 01:46:32 +01:00
Emmanuel Fleury
207b8cb8a5 Convert tests/assert-msg-test* to glib/tests/assert-msg-test*
Closes issue #1434
2022-06-28 11:19:21 +01:00
Philip Withnall
e5ccbe09da Merge branch 'atomic-exchange-pre-value' into 'main'
gatomic: Add Compare and Exchange functions that returns the previous value

See merge request GNOME/glib!2766
2022-06-23 13:19:05 +00:00
ericLemanissier
f2ea67ae44 use gvdb as a subproject
this fixes the build when using --wrap-mode=nofallback
fix proposed by @eschwartz
2022-06-23 08:26:21 +00:00
Marco Trevisan (Treviño)
922bc1d995 build: Use _GLIB prefix for GCC features we detected at build time
We used a _GCC prefix that is not our namesapce, so even if such value
is not provided by the compiler, let's just use a better name.
2022-06-22 23:01:33 +02:00
Philip Withnall
ebfbef1acd 2.73.1
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-06-21 14:02:39 +01:00
Philip Withnall
46a6f49066 Merge branch 'meson-add-test-setup' into 'main'
build: Use add_test_setup() to allow tests to be run under valgrind

See merge request GNOME/glib!2752
2022-06-20 11:09:55 +00:00
Philip Withnall
f5baecdb36 build: Use add_test_setup() to allow tests to be run under valgrind
This means we can specify the standard options for testing GLib under
valgrind consistently, so that developers can use `meson test
--setup=valgrind` to run them.

Port the existing valgrind CI to use them (this will not change its
functional behaviour).

Suggested by Marco Trevisan at
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2717#note_1478891.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-06-20 11:54:10 +01:00
Eli Schwartz
26435b570f
meson: simplify intl lookups using Meson's builtin dependency lookup
intl is complicated to look up. Some of that complexity now resides in
Meson, since 0.59.0, via a `dependency('intl')` lookup, so use that
instead.

The Meson lookup doesn't include all the checks here, but likewise this
meson.build doesn't include all the checks in Meson. Particularly, the
following are different:

- Meson accurately detects support built into libc, even if that
  conflicts with an external library version (which should be detected as
  broken and thus not-found, but glib does not do so).

  The problem here is that depending on which libintl.h header is first
  in the search path, the *gettext symbols may be the libc ABI, or they
  may be renamed to libintl_*gettext, then additionally take over the
  *gettext names via a macro, in order to invoke the external library
  version even on systems where there is a libc builtin. This means that
  checking for `cc.has_function()` correctly reports that there is such
  a function in libc, but that unfortunately does not mean it is usable,
  because source code referencing `ngettext` etc. will expect to be
  linked to `libintl_ngettext`.

- glib checks whether the found intl requires pthread, rather than
  simply trusting the result of `cc.find_library()` for the external
  library case.

Do the heavy lifting by using Meson to check for intl, and select the
correct implementation, but do a post-discovery check if the symbol is
linkable both with/without pthread.

The logic is still a bit hairy, and eventually more of the logic could
be moved into Meson. But it's better than before.

Fixes incorrect detection of intl on musl-based systems (which have a
less capable libc intl), when GNU libintl is installed as an external
library.
2022-06-16 12:04:59 -04:00
Eli Schwartz
24ec80cfb4
meson: simplify iconv lookups using Meson's builtin dependency lookup
iconv is complicated to look up. That complexity now resides in
Meson, since 0.60.0, via a `dependency('iconv')` lookup, so use that
instead.

No effort is made to support the old option for which type of iconv to
use. It was a false choice, because if only one was available, then
that's the only one you can use, and if both are available, the external
iconv shadows the builtin one and renders the builtin one unusable,
so there is still only one you can use.

This meant that when configuring glib with -Diconv=libc on systems that
had an external iconv, the configure check would detect a valid libc
iconv, try to use it, and then fail during the build because iconv.h
belongs to the external iconv and generates machine code using the
external iconv ABI, but fails to link to the iconv `find_library()`.
Meson handles this transparently.
2022-06-16 12:04:59 -04:00