* WIP: Document formal Meson grammar
* Various little fixes [skip ci]
1) Add missing logical_not_expr
2) 'in' and 'not in' are valid relational operators at least for dicts
3) dictionary keys can be expressions, but kwarg names cannot
4) typo logical_end_expression -> logical_and_expression
5) Make jump statements only allowed inside an iteration statement
* Rework EBNF style [skip ci]
As there is no good order for the productions, just go alphabetically.
The EBNF style was changed to match the one the Python lark project
uses, that is colons for productions and terminals enclosed in double
quotes.
* Add missing production for unary operators [skip ci]
* Add production for multiline strings [skip ci]
* Properly define terminal symbols [skip ci]
Depending on the EBNF flavor, regex can be used to describe the terminal
symbols. Lark allows this, and as it was mentioned as a possible user of
this grammar, let's follow its flavor here. Most regexes used are easily
human-readable, and we can always add comments to more complicated ones.
* Small changes to which expressions can be used where [skip ci]
Let the grammar be very general. The type system then has to check, that
the used expression really evaluates to the correct type. Even if we
know today that assignment expressions always evaluate to None (and can
therefore only be used as a toplevel expression in an expression
statement), this needn't be the case forever. So this way, the grammar
stays stable even if such changes were made.
* Rework function argument list production [skip ci]
* Be more verbose for production names [skip ci]
Rename expr -> expression, stmt -> statement, op -> operator, program ->
build_definition. Also adjust some list productions.
* Add paragraph about syntax stability promises [skip ci]
Update the test.json schema, adding the 'stdout' property.
Also amend the test.json schema so the presence of an unexpected
property on the root object causes a validation error.
v2:
Also add 'tools' property to json schema.
Amend the documentation not to use the word 'list' to describe a dict.
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
Expected stdout lines must match lines from the actual stdout, in the
same order. Lines with match type 're' are regex matched.
v2:
Ignore comment lines in expected_stdout
v3:
Automatically adjust path separators for location in expected output
v4:
Put expected stdout in test.json, rather than a separate file
Cosmetic tweak to the error message for incdir() with an absolute path.
Don't split the message in the middle of a sentence at a point which may
or may not correspond to the terminal width.
For the sake of a consistent error message (irrespective of if 'valac' is
present or not), check if the 'c' language is present if we are adding
'vala' before (rather than after) we do compiler detection.
Generally, we'd want to use str() rather than repr() in error messages
anyhow, as that explicitly gives something designed to be read by
humans.
Sometimes {!r} is being used as a shortcut to avoid writing the quotes
in '{!s}'.
Unfortunately, these things aren't quite the same, as the repr of a
string containing '\' (the path separator on Windows) will have those
escaped.
We don't have a good string representation to use for the arbitrary
internal object used as an argument for install_data() when it's neither
a string nor file (which doesn't lead to a good error message), so drop
that for the moment.
Currently, colourize_console is a constant, set at process
initialization.
To allow the actual stdout to be easily compared with the expected when
running tests, we want to allow colourization to be on for the test
driver, but not for the in-process configure done by run_configure,
which has stdout redirected from a tty to a pipe.
v2:
Cache _colorize_console per file object
v3:
Reset cache on setup_console()
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.
Currently it does nothing, as the field is read too late, and additional
languages have already been considered. As such if the language
requested is closer to C (for example you want C but have a C++ source
with only extern C functions) then link_langauge is ignored.
Fixes#6453
This adds support for Files, CustomTarget, Indexs of CustomTargets,
ConfigureFiles, ExternalPrograms, and Executables.
Fixes: #1234Fixes: #3552Fixes: #6175
When wiping a build tree with --wipe, every entry in the build directory
is removed with mesonlib.windows_proof_rmtree() for directories and
mesonlib.windows_proof_rm() for other files. Symlinks to directories are
considered directories, resulting in the former being called. This
causes an exception to be raised, as the implementation calls
shutil.rmtree(), which isn't allowed on symlinks.
Fix this by using mesonlib.windows_proof_rm() for symlinks.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
For instance if C:/Program Files (x86)/folder is passed to _guess_files, it would resolve to ['C:/Program Files', '(x86)/folder'] since C:/Program Files is an actual file location that can exist.
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.
* dependency: log cached or skipped dependencies with reference to modules
If the dependency is a special dependency which takes modules, the
modules get cached separately and probably reference different
pkg-config files. It's very plausible that we have multiple
dependencies, using different modules. For example:
Run-time dependency qt5 (modules: Core) found: YES 5.14.2 (pkg-config)
Dependency qt5 skipped: feature gui disabled
Obviously this makes no sense, because of course we found qt5 and even
used it. The second line is a lot more readable if it shows this:
Dependency qt5 (modules: Widgets) skipped: feature gui disabled
Similar confusion abounds in the case where a module is found in the
cache -- which module, exactly, has been found here:
Dependency qt5 found: YES 5.14.2 (cached)
Rewrite the dependency function to *consistently* pass around (and use!)
the display_name even in cases where we know it isn't anonymous (this is
just more correct anyway), and make it serve a dual purpose by also
appending the list of modules just like we do for pretty-printing that a
dependency has just been found for the first time.
* fixup! dependency: log cached or skipped dependencies with reference to modules
pointlessly cast modules to str, as they cannot be anything else. But we
want to fail later on, with something more friendly than a stacktrace.
boost/wx have special exceptions for people passing an integer there.
- 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.
Jussi Pakkanen
Michael Brockus
Daniel Mensinger
Princeton Ferro
Flow-It
Dylan Baker
James Hilliard
Jon Turney
Xavier Claessens
Laurent Pinchart
Brendan Simon
Benjamin Frye
georgev93
Eli Schwartz