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='.'`
Executables may have an entry point of wmain or wWinMain. These
executables link successfully with ninja. Rather than add more flags to
executable() in meson.build, remove the EntryPointSymbol override. This
makes the vs backend behave more like the ninja backend.
Fixes#6698
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.
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
Xavier Claessens
Nirbheek Chauhan
Daniel Mensinger
Michael Hirsch, Ph.D
Cerbero
Peter Harris
Andrei Alexeyev
Hemmo Nieminen
Jan Alexander Steffens (heftig)
Loïc Yhuel
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