The previous approach wasn't great because you couldn't control what the
detected C++ stdlib impl was. We just had a preference list we tweaked the
searched order for per OS. That doesn't work great for e.g. Gentoo with libc++
or Gentoo Prefix on macOS where we might be using libstdc++ even though the host
is libc++.
Jonathan Wakely, the libstdc++ maintainer, gave a helpful answer on how
to best detect libc++ vs libstdc++ via macros on SO [0]. Implement it.
TL;DR: Use <version> from C++20 if we can, use <ciso646> otherwise. Check for
_LIBCPP_VERSION as libstdc++ doesn't always define a macro.
[0] https://stackoverflow.com/a/31658120
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
The cuda compiler also executes the host compiler and generally needs to know
the host compiler flags. We did this for regular args but not for error args.
We use `-Xcompiler=` since that's how nvcc tells the difference between args
it uses itself for device code and args it passes to the host compiler.
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
[eli: fix quoting style]
When linking with a Rust rlib, we should also link with its external
system dependencies. This was currently done only for C ABI crates, do
it for both rlib and staticlib now.
When only a single input file shows up in an arglist, it makes no sense
to inject `-W,--start-group -lone -Wl,--end-group`, since there is
nothing being grouped together. It's just longer command lines for
nothing.
This is just a bad regex match, because it matches *.so as a prospective
filename input even though it is actually not an input but a linker
flag. --start-group is only relevant to input files...
When the proc-macro rlib is in a different subdir, it would miss the
needed -L argument and rustc would not find it. Meson was assuming that
proc-macros are only needed when building libraries that uses it, but it
turns out that was wrong, as show by the unit test.
* `-Wpedantic` creates useless churn due to its use of gcc-line directives:
../foo.cu:1:3: warning: style of line directive is a GCC extension
1 | namespace Foo {
| ^~
https://stackoverflow.com/a/31001220
Cargo implements this configuration option to override the entry point
of the library.
To get test coverage, I've modified one of the two Cargo subprojects
in the test to use a non-default library entrypoint. The other still
uses the default.
Alterations to kwargs come in two flavors:
1. Remove/replace values (delete/set)
2. Modify values (add/remove)
Only for the second flavor do we care about the type of any existing
value.
Currently, not only Meson lacks a way to induce a "--fatal-warnings" on
LINK.exe, it is also unable to pass flags appropriately when using
clang-cl or Microsoft's stock clang.
This commit fixes it by implementing `fatal_warnings()` in the
MSVCDynamicLinker and ClangCLDynamicLinker classes, and by implementing
the requisite conversion steps in linker_to_compiler_args for
ClangCompiler.
This way the `rust.bindgen` can generate a second output being a C file,
which contains wrapper functions for static inline ones.
This output file can then be compiled via C targets.
Xavier Claessens
Yegor Yefremov
Sam James
Petr Machacek
Jussi Pakkanen
Elliot
Charles Brunet
David Seifert
Eli Schwartz
Alyssa Ross
Jouke Witteveen
Dylan Baker
L. E. Segovia
Tristan Partin
dragonmux
Karol Herbst