There is nothing to "warn" about, this is a completely routine
occurence. OTOH, when something is corrupted, we should warn. Keep
the red color and "WARNING:" prefix in that case.
Example output:
$ ninja -C build
Regenerating configuration from scratch: Build directory has been generated with Meson version 0.55.999, which is incompatible with current version 0.56.0.
The Meson build system
Version: 0.56.0
...
Meson calls `path/to/clang++ --version` to guess which build toolchain the
user has picked to build the source code. For the Qualcomm LLVM toolchain,
the output have an unusual output as shown below:
```
clang version 8.0.12
Snapdragon LLVM ARM Compiler 8.0.12 (based on llvm.org 7.0+)
Target: arm-unknown-linux-gnueabi
Thread model: posix
Repository: (ssh://git-hexagon-aus.qualcomm.com:...)
InstalledDir: /pkg/qct/software/llvm/release/arm/8.0.12/bin
```
Another unusual pattern is the output of `path/to/ld.qcld --version`:
```
ARM Linker from Snapdragon LLVM ARM Compiler Version 8.0.12
ARM Linker based on LLVM version: 8.0
```
The Meson logic is modified accordingly so that Meson can correctly
determine toolchain as "LLVM aarch64 cross-compiler on GNU/Linux64 OS".
This is the expected output of
`meson --native-file native_file.ini --cross-file cross_file.ini build/aarch64-debug/`:
```
...
C++ compiler for the host machine: ... (clang 8.0.12 "clang version 8.0.12")
C++ linker for the host machine: ... ld.lld 8.0.12
...
```
This creates a full set of option in environment that mirror those in
coredata, this mirroring of the coredata structure is convenient because
lookups int env (such as when initializing compilers) becomes a straight
dict lookup, with no list iteration. It also means that all of the
command line and machine files are read and stored in the correct order
before they're ever accessed, simplifying the logic of using them.
This is like the project options, but for meson builtin options.
The only real differences here have to do with the differences between
meson builtin options and project options. Some meson options can be set
on a per-machine basis (build.pkg_config_path vs pkg_config_path) others
can be set on a per-subproject basis, but should inherit the parent
setting.
This allows adding a `[project options]` section to a cross or native file
that contains the options defined for a project in it's meson_option.txt
file.
On some systems aarch64 is reported as arm64. Due to mesons
mangling of everything that starts with arm, it would end up being
detected as arm (which implies 32 bit) which is incorrect.
Machine files already supports `+` operator as an implementation detail,
since it's using eval(). Now make it an officially supported feature and
add a way to define constants that are used while evaluating an entry
value.
Simmilar to gcc, the list of pre-processor defines can be fetched with
`-dM -E` option. The way cpu_family is determined on linux relies on
this list.
Fixes incorrect value of cpu_family on linux, when crosscompiling:
```
CC="clang -m32" meson ./build
```
Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com>
Co-authored-by: Dylan Baker <dylan@pnwbakers.com>
D lang compilers have an option -release (or similar) which turns off
asserts, contracts, and other runtime type checking. This patch wires
that up to the b_ndebug flag.
Fixes#7082
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`.
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.
Mips architectures may have `el` on the end, to differentiate the little
endian from the big endian variants. We don't encode endianness in the
cpu names, so ensure we've stripped that.
Fixes#6655
The 0.53.2 test suite has a new failure:
Traceback (most recent call last):
File "run_project_tests.py", line 1024, in <module>
detect_system_compiler()
File "run_project_tests.py", line 964, in detect_system_compiler
comp = env.compiler_from_language(lang, MachineChoice.HOST)
File "/build/meson/src/meson-0.53.2/mesonbuild/environment.py", line 1565, in compiler_from_language
comp = self.detect_cuda_compiler(for_machine)
File "/build/meson/src/meson-0.53.2/mesonbuild/environment.py", line 1131, in detect_cuda_compiler
linker = CudaLinker(compiler, for_machine, 'nvlink', CudaCompiler.LINKER_PREFIX, [], version=CudaLinker.parse_version())
File "/build/meson/src/meson-0.53.2/mesonbuild/linkers.py", line 963, in __init__
super().__init__('nvlink', *args, **kwargs)
TypeError: __init__() takes 6 positional arguments but 7 positional arguments (and 1 keyword-only argument) were given
Fixes: c708c52ca2 ("linkers: Update the linker names to be more consistent")
Emscripten does have a stand alone linker, wasm-ld. This patch adds the
linker, adds detection for the linker, and removes the IsLinkerMixin for
emscripten. This is a little more correct, and makes the code a lot
cleaner and more robust.
This is more correct, and forces the target(s) to be rebuilt if the
PDB files are missing. Increases the minimum required Ninja to 1.7,
which is available in Ubuntu 16.04 under backports.
We can't do the same for import libraries, because it is impossible
for us to know at configure time whether or not an import library will
be generated for a given DLL.
This makes two basic changes, 1 it moves the name of the linker into the
linker class, this should reduce the number of errors and typos, and
ensure that a linker always has one name. This then renames the linkers
to have more consistent names.
Posix/gnu linkers are called ld.<name>: ld.gold, ld.lld, ld.solaris.
Apple linkers are renamed ld64.
This allows Meson native-file [properties] to be used.
This avoids the need to call meson from a script file or have a
long command line invocation of `meson setup`
The method meson.get_native_property('prop', 'fallback') is added.
The native file can contain properties like
```
[properties]
myprop1 = 'foo'
mydir2 = 'lib/custom'
```
Then from within `meson.build`
```meson
x1 = meson.get_native_property('myprop1')
thedir = meson.get_native_property('mydir2', 'libs')
```
fallback values are optional
The rust code is ugly, because rust is annoying. It doesn't invoke a
linker directly (unless that linker is link.exe or lld-link.exe),
instead it invokes the C compiler (gcc or clang usually) to do it's
linking. Meson doesn't have good abstractions for this, though we
probably should because some of the D compilers do the same thing.
Either that or we should just call the c compiler directly, like vala
does.
This changes the public interface for meson, which we don't do unless we
absolutely have to. In this case I think we need to do it. A fair number
of projects have already been using 'ld' in their cross/native files to
get the ld binary and call it directly in custom_targets or generators,
and we broke that. While we could hit this problem again names like
`c_ld` and `cpp_ld` are far less likely to cause collisions than `ld`.
Additionally this gives a way to set the linker on a per-compiler basis,
which is probably in itself very useful.
Fixes#6442
* environment: Fix passing always args to a number of less common linkers
These are mostly (oops xilink) proprietary linkers I can't use for
various reasons.
Fixes: #6332
* Add intelfix from scivision.
* Ifort fix from scivision.
* PGI fix from scivision.
* Cuda fix from scivision.
* Fix linker passing for armclang.
If a user passes -fuse-ld=gold to gcc or clang, they expect that they'll
get ld.gold, not whatever the default is. Meson currently doesn't do
that, because it doesn't pass these arguments to the linker detection
logic. This patch fixes that. Another case that this is needed is with
clang's --target option
This is a bad solution, honestly, and it would be better to use $LD or a
cross/native file but this is needed for backwards compatability.
Fixes#6057