Previously, `-Wl,--export-dynamic` was in `Libs` key of `gmodule-2.0.pc`,
even though `-Wl` is a compiler flag, rather than a linker one.
This caused issues with API reference builds in evolution-data-server,
which passes the output of `pkg-config --libs` through `--ldflags`
argument of `gtkdoc-scan`, which are forwarded unchanged to `ld`:
ld: unrecognized option '-Wl,--export-dynamic'
Let’s move the flag to `Cflags` so that the compiler can deal with it.
https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/463
In all these cases we don't really care about running the test file,
while building and basic execution it is relevant.
Also they don't support TAP at all.
Meson supports tap protocol results parsing, allowing us to track better
the tests that are running (and the ones that are actually skipped) without
manually parsing the test output.
However this also implies that using the verbose mode for a test doesn't
show its output by default (unless there are failures).
We cannot use `gvisibility_h` for different visibility header files; you
never know when you're going to refer to the variable again, and
projects might end up needing to retrieve the variable contents—like,
for instance, gobject-introspection using glib as a subproject.
This should fix the Coverity build, which is currently broken:
https://gitlab.gnome.org/GNOME/glib/-/jobs/2389979
```
../gmodule/gmodule-deprecated.c:8: error: "GLIB_DISABLE_DEPRECATION_WARNINGS" redefined [-Werror]
8 | #define GLIB_DISABLE_DEPRECATION_WARNINGS
|
<command-line>: note: this is the location of the previous definition
cc1: all warnings being treated as errors
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This reverts commit 476e33c3f3.
We’ve decided to remove `G_OS_DARWIN` in favour of recommending people
use `__APPLE__` instead. As per the discussion on #2802 and linked
issues,
* Adding a new define shifts the complexity from “which of these
platform-provided defines do I use” to “which platform-provided
defines does G_OS_DARWIN use”
* There should ideally be no cases where a user of GLib has to use
their own platform-specific code, since GLib should be providing
appropriate abstractions
* Providing a single `G_OS_DARWIN` to cover all Apple products (macOS
and iOS) hides the complexity of what the user is actually testing:
are they testing for the Mach kernel, the Carbon and/or Cocoa user
space toolkits, macOS vs iOS vs tvOS, etc
Helps: #2802
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.
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.
G_MODULE_SUFFIX is deprecated now because you will get the wrong
results using it most of the time:
1. The suffix on macOS is usually 'dylib', but it's 'so' when using
Autotools, so there's no way to get the suffix correct using
a pre-processor macro.
2. Prefixes also vary in a platform-specific way. You may or may not have
a 'lib' prefix for the name on Windows and on Cygwin the prefix is
'cyg'.
3. The library name itself can vary per platform. For instance, you may
want to load foo-1.dll on Windows and libfoo.1.dylib on macOS. This
is for libraries, not modules, but that is still a use-case that
people use the GModule API for.
g_module_build_path() does take care of (2) on Cygwin, but it
fundamentally cannot handle the possibility of multiple options for
the module name, since it does not do any I/O. Hence, it is also
deprecated.
Instead, g_module_open() has been improved so that it takes care of
all this by searching the filesystem for combinations of possible
suffixes and prefixes on each platform. Along the way, the
documentation for it was also improved to make it clearer what it
does.
Closes https://gitlab.gnome.org/GNOME/glib/-/issues/520
Closes https://gitlab.gnome.org/GNOME/glib/-/issues/1413
In principle we could script this so that each max-version.c is compiled
26 times, once per possible MAX_VERSION, but I haven't implemented
that here: just pinning to the oldest possible version is sufficient to
reproduce #2796.
These aren't included in the installed-tests, since they don't really
do anything at runtime (the important thing is that they compile
without warnings).
Reproduces: #2796
Signed-off-by: Simon McVittie <smcv@collabora.com>
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.
Otherwise, the build will fail when the toolchain is static-only, even
with -Ddefault_library=static. I talked to a Meson developer in their
IRC channel, who told me that the correct fix was to ensure that
shared_library is only used if default_library != static.
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.
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>
If a `.la` file is empty, `lt_libdir` and/or `lt_dlname` won’t be set,
but will then still be used in `g_strconcat()`, leading to invalid
output.
Detect that and return an error.
Adds a unit test.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Coverity CID: #1474756
These have all been added manually, as I’ve finished all the files which
I can automatically detect.
All the license headers in this commit are for LGPL-2.1-or-later, and
all have been double-checked against the license paragraph in the file
header.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
This is the result of running `reuse download --all`.
This isn’t yet necessarily a comprehensive list of all licenses used in
GLib, as the majority of files in GLib are currently missing machine
readable copyright and licensing headers.
It’s a start though.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
As per meson spec, returncode() produces unspecified data if
compiled() == false. Check compiled() first to avoid relying
upon unspecified data.
In addition, muon -- an implemetation of meson written in C goes
further and forbids returning unspecified data. This is a good
decision, but also makes it harder to support applications which
wrongly use meson API. Therefore, application needs to be fixed.
It is not only shorter than `not meson.is_cross_build() or
meson.has_exe_wrapper()` but also handle the case of cross compiling to
a compatible arch such as building for i386 on an amd64.
