* 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]
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.
It is not unheard-of for a project to use pch for C++ but not for C
(because C usually builds fast enough anyway, so it's not worth the
developer overhead of maintaining the pch file).
This code was trying to optimize the vcxproj file size by detecting
"only one language", but it was only looking at the number of
pch-languages defined. This is incorrect when pch is not defined for all
languages in use.
Instead of tweaking the optimization further, remove it. This makes the
vs backend behave more like the ninja backend.
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
On some systems the binary 'cmake' for version 3 is named 'cmake3',
therefor printing its version number prints:
'cmake3 version X.Y.Z' instead of 'cmake version X.Y.Z'
This '3' digit in the middle breaks the regular expression
extracting the version number.
The following fix permit both way to work and the regexp to
match the proper version number.
Signed-off-by: Alexandre Lavigne <alexandre.lavigne@scality.com>
Doing this by hand is fraught with corner cases, and we're running into
some of those problems already. setuptools pkg_resource is a well tested
solution for not running into corner cases, and we already rely on
setuptools to make our entry point scripts work, so we might as well
make us of the other things it can solve for us.
Fixes#6801
Windows cmd.exe consoles may be using a code page that might choke
print() when we are outputting the output from calling gtk-doc. Let's
just ignore the error when it happens and print as much as we could in
this situation.
On Windows, prepend the commands to call the gtk-doc scripts using the
currently-used Python executable, since Windows cmd.exe consoles do not
support shebang lines.
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.
I have an NVME drive, I really don't want to be thrashing it with
temporary files. It's also annoying to watch vscode thrash about with
files that are quickly created and deleted. I'd rather put them in /tmp,
so I've added a non-default option to do so.