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.
* add support for wrap of mercurial repo, and a test with a clone of the sample subproject used for the git test into a mercuriel repo.
* Added myself to author list, and switched the URL of the sample subproject in the wrap file to one under the control of the project's maintainers.
This is the first step in making Vala support have feature-parity with
C/C++ support. Vala and Vapi sources generated with Generators and
CustomTargets are no longer ignored. Dependencies are setup properly and
they are added to the commandline.
Jussi Pakkanen