This change made `5 dependency versions` unit test fail because now once
a subproject has been configured, the fallback variable is checked to be
consistent. So it has to use new subproject because 'somesub' was
already configured by previous tests.
This test was never testing what it claimed to test, simply failing with
"ERROR: No C-like compilers are available, cannot find the framework"
because a C-like language is missing from project().
These are always failing just because the exact version constraint isn't
satisfied, e.g. "ERROR: Meson version is 0.53.999 but project requires
0.48.0"
This test was never testing what it claimed to test, simply failing with
'ERROR: First statement must be a call to project' because it's missing
project().
Since #5279, all unrecognized escape sequences are literal, so I don't
think there's anything to test here.
Add a test that trying to use a native compiler in a target after it's
been tentatively added with add_languages() without native: but isn't
actually available gives an error.
If gtest is patched to have a pkg-config file, that will report the
version, so force the 'system' method to be used when we are exercising
that an unknown version doesn't satisfy any version constraint.
If a configure_file has an install_dir set, the supported install
argument is ignored, while this should have actually higher priority
than the install_dir itself.
Also check that correct types are used for `install` and `install_dir`.
Add test to verify this.
Fixes#3983
Previously, the configuration worked fine, but the compiler raised an
error. Now, we explicitly check for the existence of files and print a
useful error message if they do not exist.
With this it is now possible to do
foobar = executable('foobar', ...)
meson.override_find_program('foobar', foobar)
Which is convenient for a project like protobuf which produces both a
dependency and a tool. If protobuf is updated to use
override_find_program, it can be used as
protobuf_dep = dependency('protobuf', version : '>=3.3.1',
fallback : ['protobuf', 'protobuf_dep'])
protoc_prog = find_program('protoc')
Refine #3277
According to what I read on the internet, on OSX, both MH_BUNDLE (module)
and MH_DYLIB (shared library) can be dynamically loaded using dlopen(), but
it is not possible to link against MH_BUNDLE as if they were shared
libraries.
Metion this as an issue in the documentation.
Emitting a warning, and then going on to fail during the build with
mysterious errors in symbolextractor isn't very helpful, so make attempting
this an error on OSX.
Add a test for that.
See also:
https://docstore.mik.ua/orelly/unix3/mac/ch05_03.htmhttps://stackoverflow.com/questions/2339679/what-are-the-differences-between-so-and-dylib-on-osx
That syntax is invalid, since decimal numbers should never have a
leading zero and octal numbers use the `0o` prefix instead.
This matches Python 3 syntax which does not accept it:
$ python3
>>> 0123
File "<stdin>", line 1
0123
^
SyntaxError: invalid token
>>>
Add a "failing" test case to confirm this property is preserved and no
regressions are introduced in this area.
This will copy the file to the build directory without trying to read
it or substitute values into it.
Also do this optimization if the configuration_data() object passed to
the `configuration:` kwarg is empty, and print a warning about it.
See also: https://github.com/mesonbuild/meson/issues/1542