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)
When doing a compile test with a testfile.c, ccache fails since the path is random.
So it's better to disable it, to avoid reporting this as a cache miss.
I've combined the two ppc checks into one, since they're not very
complicated and added power machintosh, which is used by PPC macs
running older versions of osx.
Fixes: #6746
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.
This makes use of proper ConfigTool and PkgConfig dependencies rather
than one big ExternalDependency that internally creates other
dependencies and then copies their attributes.
Basically this breaks down into three cases. An open source version with
compliant PkgConfig, valid CMake, and a Intel implementation that has
completely broken PkgConfig. For the first two cases we can use standard
classes, for the last we can make a subclass of PkgConfigDependency that
handles the special logic.
This doesn't change any of the logic, but it does re-organize it to be
clearer, and make use of the dependency factory API, which makes other
things (like Dependency.get_variable) work.
This is untested with Intel MKL.
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
If no exe_wrapper is set in the meson cross file the exe_wrapper
object will be an instance of EmptyExternalProgram.
So, found is True and prorgram is an empty list.
This will cause meson to tun the compiler sanity check because
it checks only for self.is_cross and self.exe_wrapper being
not None.
I ran into that situation while cross compiling for ia32 on a
x64_64 host. The host had no ia32 userspace installed, so the
self test failed.
As workaround I currently set exe_wrapper to 'true'.
Signed-off-by: Richard Weinberger <richard@nod.at>
getattr() requires a default (return if missing) value or it raises an
AttributeError. In a few cases I changed hasattr to getattr and didn't
set a default value, so those cases could except. This corrects that.
Clang supports the GCC -Og flag, but --optimization=g is not setting that. This is because Clang is referencing the clike_optimization_args, which does not define a flag for 'g'.
To address this, we'll mimic the GNU options instead of the C-like ones.
Fixes#6619
This should have worked before, but the inheritance order was backwards,
so we got the DCompiler before the GnuCompiler, and the base Compiler
methods overrode the Gnu methods.
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
Daniel Mensinger
Jan Alexander Steffens (heftig)
Loïc Yhuel
Xavier Claessens
Ole André Vadla Ravnås
Dylan Baker
Jon Turney
Michael Kuhn
Jussi Pakkanen
Martin Storsjö
John Ericson
John Ericson
Szabi Tolnai
alanNz
Camilo Celis Guzman
Michael
ClausKlein
Richard Weinberger
Andrei Alexeyev
Phillip Johnston