PR #6363 made it so our interpretation of env vars no longer clashed
with Autoconf's: if both Meson and Autoconf would read and env var, both
would do the same things with the value they read.
However, there were still cases that autoconf would read an env var when
meson wouldn't:
- Autoconf would use `CC` in cross builds too
- Autoconf would use `CC_FOR_BUILD` in native builds too.
There's no reason Meson can't also do this--if native cross files
overwrite rather than replace env vars, cross files can also overwrite
rather than replace env vars.
Because variables like `CC` are so ubiquitous, and because ignoring them
in cross builds just makes those builds liable to break (and things more
complicated in general), we bring Meson's behavior in line with
Autoconf's.
A couple used checks for specific compiler binaries, but those might not
be accurate for cross compiling. All the languages other than C and C++
(which we basically always assume we have) should have a
skip_if_not_lang check.
It may not be obvious to users that these two ways to set build-types
override each other and specifying both is redundant, and conflicts
are resolved based on whichever is specified later.
Closes https://github.com/mesonbuild/meson/issues/6742
With the current logic passing `--debug` will actually be parsed as
`-Ddebug=false`, which is absolutely not what is expected.
There is no case in which the presence of a boolean option in `--foo`
form will mean 'I want feature foo disabled', regardless of the
*default* value of that option.
Also includes a test.
Closes https://github.com/mesonbuild/meson/issues/4686
The previous code was assuming that options do not depend on each
other, and that you can set defaults using `dict.setdefault()`. This
is not true for `buildtype` + `optimization`/`debug`, so we add
defaults + overrides in the right order and use the options parsing
code later to compute the values.
Includes a test.
Closes https://github.com/mesonbuild/meson/issues/6752
Similar to meson.override_find_program() but overrides the result of the
dependency() function.
Also ensure that dependency() always returns the same result when
looking for the same dependency, this fixes cases where parts of the
project could be using a system library and other parts use the library
provided by a subproject.
This makes the typing annotations basically impossible to get right, but
if we only have one key then it's easy. Fortunately python provides
comprehensions, so we don't even need the ability to pass multiple keys,
we can just [extract_as_list(kwargs, c) for c in ('a', 'b', 'c')] and
get the same result.
listify shouldn't be unholdering, it's a function to turn scalar values
into lists, or flatten lists. Having a separate function is clearer,
easier to understand, and can be run recursively if necessary.
The old logic was completely broken, and didn't even assert that the
specified section was found at all. The CPU families test was broken
because of this. Luckily, the table didn't go out of sync with the
code.
It now also doesn't assume that each section has only one table. This
fixes the test now that we document the buildtype/optimization/debug
mapping in a second table inside the `Universal options` section.
* unittests: fix finding python2 if the binary is named python2
Because of the way the python module works the simplicity of the test
function is no longer valid, we need to have and additional name
parameter to make the python module work, as it doesn't look for an
entry called "python2" or "python3", only "python"
* unittests: Don't make our python 2.x check debian specific
* unittests: On macOS the python2 binary is still called python
This adds a warnings counter for subprojects that passed. This is to
encourage developpers to check warnings in the logs and hopefully fix
them. Otherwise they could be hidden in hundreds lines of logs.
This also print the error message for subprojects that did not pass. The
error message is often enough to fix the issue (e.g. missing
dependency) and it's easier than searching in the logs why a subproject
failed.
When a source file for a library is changed without adding new extern
symbols, only that library should be rebuilt. Nothing that uses it
should be relinked.
Along the way, also remove trailing `.` in all Ninja rule
descriptions. It's very confusing to see messages like:
```
Linking target mylib.dll.
```
It's confusing that the period at the end of that is not part of the
filename. Instead of removing that period manually in the tests (which
feels wrong!) just don't print it at all.
This makes two basic changes, 1 it moves the name of the linker into the
linker class, this should reduce the number of errors and typos, and
ensure that a linker always has one name. This then renames the linkers
to have more consistent names.
Posix/gnu linkers are called ld.<name>: ld.gold, ld.lld, ld.solaris.
Apple linkers are renamed ld64.
This allows users to disable writing out the inbuilt variables to
the pkg-config file as they might actualy not be required.
One reason to have this is for architecture-independent pkg-config
files in projects which also have architecture-dependent outputs.
For example : https://gitlab.freedesktop.org/wayland/weston/issues/269Fixes#4011
* Extend test_prefix_dependent_defaults unit test to cover default case
Extend test_prefix_dependent_defaults unit test to cover the default
case, when the default prefix is '/usr/local'. (On Windows, the default
prefix is 'c:/')
* Restore adjusting option defaults depending on the default prefix
Restore adjusting option defaults, depending on the default prefix.
Droppped in d778a371
Error is raised due to Elbrus Fortran compiler can't
generate debug information for now, because it's a 2-step
compiler where 1st step is code conversion from Fortran to C,
so debug information which C compiler would produce, is useless.
John Ericson
John Ericson
Jussi Pakkanen
Dylan Baker
Nirbheek Chauhan
Michael
Daniel Mensinger
Xavier Claessens
Jon Turney
Rohan Garg
Michael Hirsch, Ph.D
makise-homura