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.
i86pc may be either 32-bit or 64-bit, so use existing compiler checks
to determine if it should return 'x86' or 'x86_64'.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
In most cases instead pass `for_machine`, the name of the relevant
machines (what compilers target, what targets run on, etc). This allows
us to use the cross code path in the native case, deduplicating the
code.
As one can see, environment got bigger as more information is kept
structured there, while ninjabackend got a smaller. Overall a few amount
of lines were added, but the hope is what's added is a lot simpler than
what's removed.
the problem here is, that get_custom_target_provided_libraries iterated
over all generated sources of a target. In each output we check if this
is a library or not. In projects like EFL we have added a lot of
generated target to many different targets, so the iterating of the
output is rather consistent, with this commit we drop from 19% of the
time spending in get_custom_target_provided_libraries down to 3.51%.
Handling the PKG_CONFIG_PATH variable in meson introduces a new problem
for caching dependencies. We want to encode the pkg_config_path (or
cross_pkg_config_path if we're cross compiling) to be part of the key,
but we don't want to put that into the key for non-pkg-config
dependencies to avoid spurious cache misses (since pkg_config_path isn't
relevant to cmake, for example). However, on a cache lookup we can't
know that a dependency is a pkg-config dependency until we've looked in
the cache.
My solution is a two layer cache, the first layer remains the same as
before, the second layer is a dict-like object that encapsulates the
dependency type information and uses pkg_config_path and
cross_pkg_config_path as a sub key (and could be extended easily for
other types). A new object type is introduced to encapsulate this so
that callers don't need to be aware of the implementation details.
Dylan Baker
Michael Hirsch, Ph.D
Jussi Pakkanen
Olexa Bilaniuk
Ting-Wei Lan
Andrei Alexeyev
Aleksey Gurtovoy
Gabriel Ganne
Alan Coopersmith
Kramer Peace
Nirbheek Chauhan
nia
Jan Beich
Charlie Barto
Kurtis Rader
Dan Kegel
John Ericson
Marcel Hollerbach
Jon Turney