fixes regression for systems with nvcc installed--perhaps why not previously caught on CI.
Just a simple typo--missing a positional argument to CudaCompiler()
0c22798b1a is the first bad commit File
"meson\mesonbuild\environment.py", line 1066, in detect_cuda_compiler
return CudaCompiler(ccache + compiler, version, for_machine, is_cross, exe_wrap, host_compiler=cpp_compiler,
linker=linker)# Please enter the commit message for your changes. Lines starting
TypeError: __init__() missing 1 required positional argument: 'info'# with '#' will be ignored, and an empty message aborts the commit.
Now that the linkers are split out of the compilers this enum is
only used to know what platform we're compiling for. Which is
what the MachineInfo class is for
This is similar to what we currently do for scan-build except there is
no environment variable to choose a specific clang-format to run. If an
environment variable is needed for better control, we can add it later.
Both scan-build and llvm-config need the same list of LLVM version
suffixes. It is better to keep the list at a common place instead of
having several copies in different files, which is likely to become
out-of-sync when the list is updated.
Versioning of executables is not related to the operating system kernel.
It is possible for a Linux distribution to support multiple versions of
LLVM in a way similar to FreeBSD. For example, on Debian, you can use
'apt install clang-tools-7' to install the versioned 'scan-build-7'
executable without bringing the unversioned 'scan-build' into the
environment. Therefore, we should not skip the version list on Linux.
It also makes it consistent with the behavior of llvm dependency, which
does not change the search list depending on the operating system.
This commit also fixes the version suffix for Debian. Debian stops using
the minor version number on the executable after version 7, so it should
be 'scan-build-7', not 'scan-build-7.0'.
This is a follow-up of https://github.com/mesonbuild/meson/pull/5918.
Detect scan-build the same way when trying to launch it and when
generating the target.
The detection method is:
1. look within SCANBUILD env variable
2. shutil.which('scan-build')
3. *on non-linux platforms only*: go through all the possible
name candidates and test them individually.
The third step is added following this comment
https://github.com/mesonbuild/meson/pull/5857#issuecomment-528305788
However, going through a list of all the possible candidates is neither
easily maintainable nor performant, and is therefore skipped on
platforms that should not require such a step (currently, only Linux
platforms).
This is a follow-up to the issue raised by @lantw44 during PR:
https://github.com/mesonbuild/meson/pull/5857
Solaris 11.3 & earlier sent the --version output to stderr, but
Solaris 11.4 moved it to stdout in an attempt to be more compatible
with the GNU tools, so look for it in both streams of output.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
llvm-mingw uses a wrapper script to inject (among other things) a
-target argument into the clang command, which breaks -Wl,--version.
This confuses Meson into thinking the linker is some unknown version of
Apple ld, which breaks builds.
This patch makes it detect and recover from the issue.
Fixes#5910
Instead of the DynamicLinker returning a hardcoded value like
`-Wl,-foo`, it now is passed a value that could be '-Wl,', or could be
something '-Xlinker='
This makes a few things cleaner, and will make it possible to fix using
clang (not clang-cl) on windows, where it invokes either link.exe or
lld-link.exe instead of a gnu-ld compatible linker.
The regex was incorrect, so it was matching 'ARM64' with 'ARM'.
Make the regex more specific so that it matches:
Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27031.1 for x64
Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27031.1 for x86
Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27031.1 for ARM64
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86
etc.
These two functions are different only in the classes that they use, a
couple of simple in-line ternaries takes care of that and reduces code
duplication.
* coredata: Correctly handle receiving a pipe for native/cross files
In some cases a cross/native file may be a pipe, such as when using bash
process replacement `meson --native-file
<([binaries]llvm-config='/opt/bin/llvm-config')`, for example. In this
case we copy the contents of the pipe into a file in the meson-private
directory so we can create a proper ninja dependency, and be able to
reload the file on --wipe/--reconfigure. This requires some extra
negotiation to preserve these native/cross files.
Fixes#5505
* run_unitests: Add a unit test for native files that are pipes
Using mkfifo.