This is the common Python convention for private methods
so lets not expose these to build files as they are
implementation details and their behavior is undefined.
All assignments in meson should be by value, so mutable objects
(i.e. environment() and configuration_data()) should be copied
automatically on assignment.
Fixes#831.
We should only silently return from a dependency() call if the error is
transient (old version, wrap failed to download etc), not if the
subproject invocation or dependency name are incorrect.
For instance, if you use a dependency(..., fallback : ...) call in
a meson.build not in the root directory, we would always ignore the
call instead of erroring out due to invalid usage.
We should consider categorising our exceptions in this manner elsewhere
too.
If building in a prefix with a version of the library that's already
installed with other dependencies already installed in that prefix,
then the installed library was being picked up to link with
for gir generation instead of the newly built library.
If first checking for a dependency as not-required, and then later
checking for the same dependency again as required, we would not
error out saying the dependency is missing, but just silently
re-use the cached dependency object from the first check and then
likely fail at build time if the dependency is not actually there.
With test case.
Fixes#964.
Not all headers are public, or contain public types. GTK-Doc allows
adding headers to be ignored during the "scan" phase, by passing the
`--ignore-headers` command line argument to gtkdoc-scan.
Currently, you can do something like:
ignored_headers = [ 'foo-private.h', 'bar-private.h', ]
gnome.gtkdoc(...
scan_args: [
'--ignore-headers=' + ' '.join(ignored_headers),
],
...)
But it does not guarantee escaping rules and it's definitely not nice.
We can add a simpler version of that mechanism through a new positional
argument, `ignore_headers`, which behaves like `content_files` or
`html_assets`, and takes an array of header files to ignore:
gnome.gtkdoc(...
ignore_headers: ignored_headers,
...)
If a `<modulename>-overrides.txt` file exists in the docs directory it
means it's intended to be used in place of the one gtk-doc generates.
GLib and GTK+, for instance, ship with one because some of the types
they provide — like the thread primitives, or the platform macros —
contain architecture-dependent fields that should not be accessed
directly.
This commit should close the last bit of issue #550.
Make so both executable() targets that are marked as native and
external programs (which are usually build tools compiled for the
host machine) are not supposed to be run with the exe wrapper.
Every other build system does this, and at least OS X, iOS, and Android
depend on this to select the OS versions that your application is
targetting.
At the same time, just use a wrapper for self.run and self.links to
share the common (identical) code.
Seems better to do this since the behaviour is compiler-specific. Would
be easier to extend this later too in case we want to do more
compiler-specific things.
Simply placing a reference to it isn't enough for the linker to try and
think it's being used and do a symbol availability check with
-Wl,-no_weak_imports on OS X ld.
Specifically, wherever we have sources or outputs, we want to use an
OrderedDict so that the build is always deterministic. It was reported
by Olexa Bilaniuk that `ar D` creates static libraries with different
checksums depending on the order of the object files.
See: https://github.com/mesonbuild/meson/pull/951
We don't actually want to preserve the order in which they are listed.
We just want the order to be deterministic and predictable.
This is needed to ensure that symbol availability checks actually fail
at link time (instead of at runtime) which is necessary for has_function
to work correctly.
The Autoconf-style check we were doing gives false positives when the
linker uses the prototype defined in the SDK header to decide whether
a function is available or not.
For example, with macOS 10.12, clock_gettime is now implemented
(alongwith other functions). These functions are always defined in the
XCode 8 SDK as weak imports and you're supposed to do a runtime check to
see if the symbols are available and use fallback code if they aren't.
The linker will always successfully link if you use one of those symbols
(without a runtime fallback) even if you target an older OS X version
with -mmacosx-version-min. This is the intended behaviour by Apple.
But this makes has_function useless because to test if the symbol is
available, we must know at link-time whether it is available.
To force the linker to do the check at link-time you must use
'-Wl,-no_weak_imports` *and* use the prototype in time.h which has an
availability macro which tells the linker whether the symbol is
available or not based on the -mmacosx-version-min flag.
An autoconf-style check would override this prototype and use its own
which would result in the linker thinking that the function is always
available (a false positive). Worse, this would manifest at runtime and
might not be picked up immediately.
We now use the function prototype in the user-provided includes if the
'prefix' kwarg contains a `#include` and use the old Autoconf-style
check if not. I've tested that the configure checks done by GStreamer
and GLib are completely unaffected by this; at least on Linux.
The next commit will also add `-Wl,-no_weak_imports` to extra_args by
default so that Meson avoids this mess completely. We always want this
because the user would not do a has_function check if they have
a runtime fallback for the function in their code.
For each project this creates a <project>-update-po target.
When ran this updates the pot file and then merges it back
into the po files in the source directory with `msgmerge`
for project maintainers and translators.
Fixes#819
The error message is misleading (talks about external dependencies), and
doesn't tell you what you need to do (use the output of
declare_dependency, dependency, or find_library). At the same time
rename add_external_deps to add_deps since it adds internal deps too.
Plus many more error message improvements all over the place.
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.
The use of has_dir_part is a terrible back that we need to move away
from. This will eventually be fixed by always using File() objects
everywhere. For now, this is needed for unity builds to work.
Patrick Griffis
Tim-Philipp Müller
Nirbheek Chauhan
Matthew Waters
Scott D Phillips
Jussi Pakkanen
Emmanuele Bassi
Mark Schulte
Guillaume Poirier-Morency
Aurelien Jarno
Jouni Kosonen