so: when building compile args, meson is deduplicating flags. When a
compiler argument is appended, a later appearance of a dedup'ed is going
to remove a earlier one. If the argument is prepended, the element
*before* the new one is going to be removed. And that is where the
problem reported in https://github.com/mesonbuild/meson/pull/7119 is
coming in. In the revision linked there, the order of replacement in the
prepend case was revesered.
With this patch, we restore this behaviour again.
Otherwise a wrapper script which takes an executable as an argument will
mistakenly run when that executable is cross compiled. This does not
wrap said executable in an exe_wrapper, just skip it.
Fixes#5982
If an executable is passed as an argument to a script in the build
directory that it resides in then it will not execute (on *nix) due to a
lack of ./. Ie, `foo` must be called as `./foo`. If it is called from a
different directory it will work. Ie `../foo` or `bar/foo`.
Fixes#5984
Gtest can output junit results with a command line switch. We can parse
this to get more detailed results than the returncode, and put those in
our own Junit output. We basically just throw away the top level
'testsuites' object, then fixup the names of the tests, and shove that
into our junit.
If the feature hadn't been broken in the first place it would have
worked on them anyway, so we might as well expose it. I'm loathe to do
it because one of the best features of meson in a mixed C/C++ code base
is that meson figures out the right linker every time, but there are
cases people have where they want to force a linker. We'll let them keep
the pieces.
JUnit is pretty ubiquitous, lots of services and results viewers
understand it, in particular gitlab and jenkins know how to consume
JUnit xml. This means projects using CI services can have their test
results consumed automatically.
Fixes: #6972
A current rather untyped storage of options is one of the things that
contributes to the options code being so complex. This takes a small
step in synching down by storing the compiler options in dicts per
language.
Future work might be replacing the langauge strings with an enum, and
defaultdict with a custom struct, just like `PerMachine` and
`MachineChoice`.
This does a couple of nice things, one is that editors like vscode can
be configured to use this schema to provide auto completion and error
highlighting if invalid values are added or required values are missing.
It also allows us test that the format of the test matrix work in a unit
test, which I've added. It does require that the python jsonschema
package is installed.
It can happen that a server is temporaly down, tarballs often have
many mirrors available so we should be able to add at least one fallback
mirror in wrap files.
* cmake: enhance support of cmake config file syntax
Enhance the cmakedefine support by accepting 2 or 3 tokens
in the conf line as mesondefine supports strictly 2 tokens
* fixup! cmake: enhance support of cmake config file syntax
* fixup! fixup! cmake: enhance support of cmake config file syntax
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
