It was generating an extra comma.
The Meson build system
Version: 0.54.0
Source dir: /tmp/tmp34halxhe
Build dir: /tmp/tmp34halxhe/build
Build type: native build
meson.build:6:15: ERROR: Expecting rparen got comma.
'Foo.java',,
^
For a block that started at 5,3
jar('tmp34halxhe',
^
A full log can be found at /tmp/tmp34halxhe/build/meson-logs/meson-log.txt
Using "tmp34halxhe" (name of current directory) as project name.
Using "tmp34halxhe" (project name) as name of executable to build.
Detected source files: Foo.java
Detected language: java
Generated meson.build file:
project('tmp34halxhe', 'java',
version : '0.1',
default_options : ['warning_level=3'])
jar('tmp34halxhe',
'Foo.java',,
main_class: tmp34halxhe,
install : true)
It was also missing quotes around the main class name.
The Meson build system
Version: 0.54.0
Source dir: /tmp/tmpjm5cg44a
Build dir: /tmp/tmpjm5cg44a/build
Build type: native build
Project name: tmpjm5cg44a
Project version: 0.1
Java compiler for the host machine: javac (unknown 1.8.0)
Host machine cpu family: x86_64
Host machine cpu: x86_64
meson.build:5:0: ERROR: Unknown variable "tmpjm5cg44a".
A full log can be found at /tmp/tmpjm5cg44a/build/meson-logs/meson-log.txt
Using "tmpjm5cg44a" (name of current directory) as project name.
Using "tmpjm5cg44a" (project name) as name of executable to build.
Detected source files: Foo.java
Detected language: java
Generated meson.build file:
project('tmpjm5cg44a', 'java',
version : '0.1',
default_options : ['warning_level=3'])
jar('tmpjm5cg44a',
'Foo.java',
main_class: tmpjm5cg44a,
install : true)
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>
With this running `meson compile` inside the builddir actually works,
and you don't have to do `meson compile -C .`
Clearly this was the intent since the option already has `default='.'`
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
Remove some weirdness from test output such as extra commas, missing
spaces and way too precise time durations. Also improve the overall
alignment of the output.
Rather than having two separate sections with duplicated information
lets just have one for the common settings, and only document sections
specific to each file in separately
The previous diagnosis (that the wrapper that injects the -target
option to clang caused the issues) doesn't seem right; the issue
was that LLD's MinGW frontend (which is invoked when ld.lld is given
a COFF argument to the -m option) didn't handle the --version argument
before LLD 9.0.0.
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.