Discussions in #6524 have shown that there are various possible uses of the
kconfig module and even disagreements in the exact file format between
Python-based kconfiglib and the tools in Linux. Instead of trying to
reconcile them, just rename the module to something less suggestive and
leave any policy to meson.build files.
In the future it may be possible to add some kind of parsing through
keyword arguments such as bool_true, quoted_strings, etc. and possibly
creation of key-value lists too. For now, configuration_data objects
provide an easy way to access quoted strings. Note that Kconfig stores
false as "absent" so it was already necessary to write "x.has_key('abc')"
rather than the more compact "x['abc']". Therefore, having to use
configuration_data does not make things much more verbose.
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.
Initially produced using:
for d in "test cases/failing/"* ; do rm -r _build ; ./meson.py setup "$d" _build | grep ERROR >"$d"/expected_stdout.txt; done
then converted to json with jq using:
jq --raw-input --slurp 'split("\n") | {stdout: map({line: select(. != "")})}' expected_stdout.txt >test.json
or merged with existing json using:
jq --slurp '.[0] + .[1]' test.json expected.json >test.json.new
v2:
Add some comments to explain the match when it isn't totally obvious
v3:
Add or adjust existing re: in expected output to handle '/' or '\' path
separators appearing in message, not location.
v4:
Put expected stdout in test.json, rather than a separate expected_stdout.txt file
Park comments in an unused 'comments' key, as JSON doesn't have a syntax for comments
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.
This adds support for Files, CustomTarget, Indexs of CustomTargets,
ConfigureFiles, ExternalPrograms, and Executables.
Fixes: #1234Fixes: #3552Fixes: #6175
Adds the `tools` section to `tests.json` to specify requirements
for the tools in the environment. All tests that fail at least
one tool requirements check are skipped.
- ExternalProgramHolder has path() method while CustomTargetHolder and
BuildTargetHolder have full_path().
- The returned ExternalProgramHolder's path() method was broken, because
build.Executable object has no get_path() method, it needs the
backend.
- find_program('overridden_prog', version : '>=1.0') was broken because
it needs to execute the exe that is not yet built. Now assume the
program has the (sub)project version.
- If the version check fails, interpreter uses
ExternalProgramHolder.get_name() for the error message but
build.Executable does not implement get_name() method.
By building the generator for the build machine always, and only for the
host machine if an exe_wrapper is available. This makes sense to me as
generally you are going to build the generator for the build machine,
not the host machine, but testing on the host machine makes sense too.
The arithmetic operators are now split into two groups:
* The add/sub group: +, -
* The mul/div group: *, /, %
All operators within the same group are left-associative and have equal
precedence. The mul/div group has a higher precedence than the add/sub
group, as one would expect.
Previously every operator had a different precedence and was
right-associative, which resulted in surprising behavior.
This is a potentially breaking change for projects that relied on the
old incorrect behavior.
Fixes#6870
This make relative pathes shorter an too give a chance to
de-duplicate -isystem flags just like -I flags.
Fix common test case 203 for OSX build host too
Some compilers that act as linker drivers (dmd and ldc) need to split
arguments that GCC combines with , (ie, -Wl,-foo,bar -> -L=-foo -L=bar).
As such we need to detect that the previous argument contained -soname,
and not wrap that in a --start-group/--end-group
This modifies the shared library test to demonstrate the problem, with a
test case.
Fixes#6359
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
This is needed when mixing D and C code, as it's possible to end up
witha combination of linkers and compilres such that C produces pdb
files but D does not.
This allows the harness to apply the version correctly, putting it in the right
place, dropping the right amount of numbers, etc.
pdb taking a version allows it to be more easily copied from the
shared_lib type.