The `mkenums` functions can have this unset if, and only if, the
c file only variant is called. Due to side effects if the header file is
generated then `install_dir` is ensured to be set for the c file. I have
removed this side effect so that our tests actually cover this case.
Fixes#9472
See https://gitlab.gnome.org/GNOME/glib/-/issues/600
`volatile` was previously mistakenly used in GLib to indicate that a
variable was accessed atomically or otherwise multi-threaded. It’s not
meant for that, and up to date compilers (like gcc-11) will rightly warn
about it.
Drop the `volatile` qualifiers.
Based on a patch by Jeff Law.
See also http://isvolatileusefulwiththreads.in/c/.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
D lang compilers have an option -release (or similar) which turns off
asserts, contracts, and other runtime type checking. This patch wires
that up to the b_ndebug flag.
Fixes#7082
* Never install the glib-mkenums generated C source
When using gnome.mkenums_simple() we end up installing the generated
C source file alongside the C header file, if `install_header` is set
to True. This is caused by mkenums_simple() acting as a wrapper for
mkenums() without template files; mkenums() won't be able to know if
we're generating the header or the source, and will use the presence
of `install_header` as the deciding factor as to whether the generated
file should be installed.
When generating the C source file, we should always unset the
`install_header` option to False, just like mkenums() expects.
Closes#3373
* Verify that mkenums_simple() does not install C sources
When asked to installed the generated C header file.
99% of all mkenums uses in C libraries use the same basic template,
so add a mkenums_simple() function that takes care of everything for
us based on that template.
Features:
- optional function declaration decorator such as GLIB_AVAILABLE
- optional extra header prefix (e.g. for include needed for decorator)
- optional extra body prefix (e.g. for additional includes)
- optional function name prefix (e.g. to add leading underscores)
Fixes issue #1384
Not only does extract_all_objects() now work properly again,
extract_objects() also works if you specify a subset of sources all of
which have been compiled into a single unified object.
So, for instance, this allows you to extract all the objects
corresponding to the C sources compiled into a target consisting of
C and C++ sources.