@TingPing has a repository that contains a grammar for meson which is
used by linguist (GitHub), and by many editors such as Atom, VS Code,
TextMate, Sublime Text, etc. Add CI so that we notice that the
function list in it is out of date, such as https://github.com/TingPing/language-meson/pull/3
It's harder to do this generically for other syntax such as the `in`
keyword, but it's better than nothing.
This reverts the changes to the `section` key for the
buildoptions and moves the machine choice into it's
own `machine` key.
With this commit the __undocumented__ breaking change
to the introspection format (introduced in 0.51.0) is
reverted and a new key is added instead.
Instead of trying to guess whether we need py or python3, and then
falling over when whatever we guessed isn't in the path or isn't right,
just use sys.executable which should always work.
* coredata: Correctly handle receiving a pipe for native/cross files
In some cases a cross/native file may be a pipe, such as when using bash
process replacement `meson --native-file
<([binaries]llvm-config='/opt/bin/llvm-config')`, for example. In this
case we copy the contents of the pipe into a file in the meson-private
directory so we can create a proper ninja dependency, and be able to
reload the file on --wipe/--reconfigure. This requires some extra
negotiation to preserve these native/cross files.
Fixes#5505
* run_unitests: Add a unit test for native files that are pipes
Using mkfifo.
We were setting the base options for the Objective-C compiler
manually, due to which options such as b_bitcode and b_ndebug were not
getting set at all.
The base options here are the same as for C code with the Clang
compiler, so just use the same inherited list.
Also expand the bitcode test to ObjC and ObjC++ so this doesn't happen
again.
In most cases instead pass `for_machine`, the name of the relevant
machines (what compilers target, what targets run on, etc). This allows
us to use the cross code path in the native case, deduplicating the
code.
As one can see, environment got bigger as more information is kept
structured there, while ninjabackend got a smaller. Overall a few amount
of lines were added, but the hope is what's added is a lot simpler than
what's removed.
It was using ':' as a path separator while GCC uses ';' resulting in bogus
paths being returned. Instead assume that the compiler uses the platform native
separator.
The previous splitting code still worked sometimes because splitting
"C:/foo;C:/bar" resulted in the last part "/bar" being valid if "<DriveOfCWD>:/bar"
existed.
The fix also exposes a clang Windows bug where it uses the wrong separator:
https://reviews.llvm.org/D61121 . Use a regex to fix those first.
This resulted in linker errors when statically linking against a library which
had an external dependency linking against system libs.
Fixes#5386
Currently this test assumes that the user doesn't have XDG_DATA_HOME
set in their path, but this isn't a good assumption, and can result in
the test not actually testing what it means to.
Meson itself *almost* only cares about the build and host platforms. The
exception is it takes a `target_machine` in the cross file and exposes
it to the user; but it doesn't do anything else with it. It's therefore
overkill to put target in `PerMachine` and `MachineChoice`. Instead, we
make a `PerThreeMachine` only for the machine infos.
Additionally fix a few other things that were bugging me in the process:
- Get rid of `MachineInfos` class. Since `envconfig.py` was created, it
has no methods that couldn't just got on `PerMachine`
- Make `default_missing` and `miss_defaulting` work functionally. That
means we can just locally bind rather than bind as class vars the
"unfrozen" configuration. This helps prevent bugs where one forgets
to freeze a configuration.
The Intel compiler is strange. On Linux and macOS it's called ICC, and
it tries to mostly behave like gcc/clang. On Windows it's called ICL,
and tries to behave like MSVC. This makes the code that's used to
implement ICC support useless for supporting ICL, because their command
line interfaces are completely different.
pkg-config(1) on OpenBSD is not the one from freedesktop.org and hence has
subtle differences (which don't impact real usage). The meson test fails
because white space between operators are stripped by our pkg-config:
$ grep Require /usr/local/lib/pkgconfig/xmlsec1.pc
Requires: libxml-2.0 >= 2.8.0 libxslt >= 1.0.20
$ pkg-config --print-requires xmlsec1
libxml-2.0>=2.8.0
libxslt>=1.0.20
There actually is an ICC for windows that can be used to cross compile
from Windows to Linux, but it's not supported in meson currently and I
don't plan to enable it.
Currently C++ inherits C, which can lead to diamond problems. By pulling
the code out into a standalone mixin class that the C, C++, ObjC, and
Objc++ compilers can inherit and override as necessary we remove one
source of diamonding. I've chosen to split this out into it's own file
as the CLikeCompiler class is over 1000 lines by itself. This also
breaks the VisualStudio derived classes inheriting from each other, to
avoid the same C -> CPP inheritance problems. This is all one giant
patch because there just isn't a clean way to separate this.
I've done the same for Fortran since it effectively inherits the
CCompiler (I say effectively because was it actually did was gross
beyond explanation), it's probably not correct, but it seems to work for
now. There really is a lot of layering violation going on in the
Compilers, and a really good scrubbing would do this code a lot of good.
For consistency, it can be useful to have an explicit empty test suite list
for a test:
test('test-name', binary, suite: [])
This currently passes meson but fails when running meson tests:
Traceback (most recent call last):
File "/usr/lib/python3.7/site-packages/mesonbuild/mesonmain.py", line 122, in run
return options.run_func(options)
File "/usr/lib/python3.7/site-packages/mesonbuild/mtest.py", line 1005, in run
return th.doit()
File "/usr/lib/python3.7/site-packages/mesonbuild/mtest.py", line 756, in doit
self.run_tests(tests)
File "/usr/lib/python3.7/site-packages/mesonbuild/mtest.py", line 896, in run_tests
visible_name = self.get_pretty_suite(test)
File "/usr/lib/python3.7/site-packages/mesonbuild/mtest.py", line 875, in get_pretty_suite
rv = TestHarness.split_suite_string(test.suite[0])[0]
IndexError: list index out of range
Fix it by simply checking for the test suite to be a valid list we can pass on
Fixes#5340
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Before this we only covered >, <, and ==, but we an apply some basic
logic to know that a > b == !(a <= b), or that if a > b then a != b.
This uncovered some bugs I wrote while working on this code.
We really should be testing using the operators themselves, not the
internal implementations, ie we should use a > b not a.__cmp__(b) == 1
in our tests, because __cmp__ is just an implementation detail.
Jussi Pakkanen
Nirbheek Chauhan
Daniel Mensinger
Dylan Baker
David Seifert
Xavier Claessens
Michael Hirsch, Ph.D
Aleksey Gurtovoy
John Ericson
John Ericson
Christoph Reiter
Antoine Jacoutot
Martin Hostettler
Peter Hutterer