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.
We had gcc-only implementations for them while both can be used in all
the supported platforms we have.
So let's just provide generic definitions, while we keep the old ones
for both consistency and retro-compatibility.
We should mention glib-mkenums in the documentation for
G_DEFINE_ENUM_TYPE and G_DEFINE_FLAGS_TYPE.
We should also mention the macros in the documentation for glib-mkenums.
This way, developers can choose the most appropriate tool for their use
case.
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
Atomic primitives allow to do conditional compare and exchange but also
to get the value that was previously stored in the atomic variable.
Now, we provided an exchange function that allows to do an exchange if
the atomic value matches an expected value but we had no way to know
at the same time what was the value in the atomic at the moment of the
exchange try, an this can be useful in case that the operation fails,
for example if the current value is still acceptable for us, allowing
to do a kind of "OR" check:
gint old_value;
gint valid_value = 222;
while (!g_atomic_pointer_compare_and_exchange_value (&atomic,
valid_value, 555,
&old_value)
{
if (old_value == 555 || old_value == 222)
valid_value = old_value;
}
While it's possible to create a directory synchronously via
g_dir_make_tmp(), there's no such API that performs it asynchronously.
So implement it using GFile, using a thread to perform such task.
Listing a user in `glib.doap` is important for ensuring their access
rights are correct in GitLab (as they are synced from the DOAP file by a
sysadmin script).
When `CODEOWNERS` was written, we were assuming that GNOME’s GitLab
would get support for the `CODEOWNERS` feature in GitLab. Unfortunately,
that’s not happened, and it remains an enterprise-only feature.
As such, that means that listing a co-maintainer of GLib in `CODEOWNERS`
is not sufficient to grant them permissions to actually merge MRs or
triage issues. That means they can’t really do any co-maintaining.
So fix that by updating the DOAP from `CODEOWNERS`. This doesn’t change
the list of co-maintainers at all, or the amount of trust assumed of
anybody.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This documents what we already do, rather than trying to make any
improvements to the process. They can happen separately, later, as
they’re a little more involved than just writing a Markdown document.
For example, we really should automate some of this.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
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.
Rather than carrying the copylib around inside GLib, which is a pain to
synchronise and affects our code coverage statistics.
This requires updating the CI images to cache the new subproject,
including updating the `cache-subprojects.sh` script to pull in git
submodules.
It also requires adding `gioenumtypes_dep` to be added to the
dependencies list of `libgio`, since it needs to be build before GVDB as
it’s pulled in by the GIO headers which GVDB includes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2603
The interface was ready for this API but it was not provided.
So implement this, using a thread that calls the sync API for now.
Add tests.
Helps with: GNOME/glib#157
This documents our existing testing best practices, and tries to explain
some of the rationale around them.
There’s some new policy around performance tests, specifying that they
are good to keep around if they are high quality (so they can be used
again, the effort put into them not thrown away, and the numbers
compared over time) and that they should be runnable automatically to
avoid bitrot.
Everything else just documents existing practice.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Atomic APIs provide a way to exchange values only if we compare a value
that is equal to the old value, but not to just exchange the value
returning the old one.
However, compilers provide such built-in functions, so we can use them
to expose such functionality to GLib.
The only drawback is that when using an old version of gcc not providing
atomic APIs to swap values, we need to re-implement it with an
implementation that may not be fully atomic, but that is safe enough.
However this codepath should really not be used currently as gcc
introduced __atomic_exchange_n() at version 4.7.4, so 8 years ago.
GArray supports a "zero_terminated" flag, but GPtrArray doesn't.
This is odd, because especially for a pointer array it makes sense
to have a %NULL sentinel. This would be for example useful to track
or construct a strv array with a GPtrArray.
As workaround for this missing feature you could use a GArray instead
(ugly) or to explicitly add the %NULL element. However the latter increases
the "len" of the array, which can be problematic if you want to still use
the GPtrArray for other purposes.
Add API for marking a GPtrArray as %NULL terminated. In that case, the
API will ensure that there is always a valid %NULL sentinel after the
array. Note that the API does not enforce that a %NULL terminated API
actually has any data allocated. That means, even with a %NULL terminated
array, pdata can still be %NULL (only if len is zero).
Add g_ptr_array_new_null_terminated() constructor. The null-terminated flag
cannot be cleared. Once the GPtrArray is flagged to be %NULL terminated, it
sticks. The purpose is that once a user checks whether a GPtrArray instance
is safe to be treated as a %NULL terminated array, the decision does
not need to be re-evaluated.
Also add a g_ptr_array_is_null_terminated(). That is useful because it
allows you to check whether a GPtrArray created by somebody else is safe
to use as a %NULL terminated array. Since there is no API to make an
array not %NULL terminated anymore, this is not error prone.
The new flag is tracked as a guint8 in GRealPtrArray. On common 64 bit
architectures this does not increase the size of the struct as it fits
in an existing hole. Note that this is not a bitfield because it's
probably more efficient to access the entire guint8. However, there is
still a 3 bytes hole (on common 32 and 64 architectures), so if we need
to add more flags in the future, we still have space for 24 bits,
despite the new flag not being a bitfield.
The biggest downside of the patch is the runtime overhead that most
operations now need to check whether %NULL termination is requested.
Includes some tweaks and additional tests by Philip Withnall.
https://gitlab.gnome.org/GNOME/glib/-/issues/353
Many idle and timeout sources are installed as "one shot": called once
and immediately removed. While it's easy to write a simple callback that
returns G_SOURCE_REMOVE, it would also be useful to have some sort of
"visual" marker when reading the code; a way to immediately see that a
callback (which may be defined elsewhere in the code) is meant to be
invoked just once.
Includes additional unit tests by Philip Withnall.
This is more efficient than calling
g_datalist_id_remove() multiple times
in a row, since it only takes the locks
once.
Allow up to 16 keys to be removed in one go.
That is enough for the use we have in GObject,
and it avoids any danger of blowing the stack.
This describes how releases are planned and scheduled, and where users
of GLib can look to see what the current (loose) roadmap is.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Make it a bit clearer in the documentation that using
`G_PARAM_STATIC_STRINGS` everywhere is a good thing.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This tries to encode all the decision making which goes on when working
out whether to backport a commit from the unstable to stable branch.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This just updates the list to reflect what we currently have in CI,
rather than any radical changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
These files are Markdown-ified versions of the following wiki pages:
* https://wiki.gnome.org/Projects/GLib/CompilerRequirements
* https://wiki.gnome.org/Projects/GLib/SupportedPlatforms
Keeping the files in version control with the rest of the documentation
means they should be easier to find, and easier to remember to keep up
to date.
They have not been modified other than to change to Markdown and tweak
the formatting. Content updates to them will be done in future commits.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This is part of an effort to rationalise our developer documentation a
bit, putting it all in one directory rather than cluttering up the root
directory.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
