Allow to set a CMAKE_CUDA_STANDARD different from CMAKE_CXX_STANDARD

[aurianer]

Fixes #699

• Add a CI config using a different CXX and CUDA standard
• Add a GPU stdexec config with different CXX and CUDA standards

Note: Looks like there are problems with fmt@10, will look into it in a separate PR.

[aurianer]

bors try

[bors]

try

Build failed:

• ci/circleci: arm64_build

[aurianer]

bors try

[bors]

try

Build failed:

• jenkins/cscs-daint/gcc-cuda-11-debug

[aurianer]

bors try

[bors]

try

Build failed:

• github/macos/debug

[aurianer]

bors try

[bors]

try

Build failed:

• ci/circleci: cmake_format

[aurianer]

bors try

[bors]

try

Build failed:

• ci/circleci: arm64_build

[aurianer]

Looks good now :)

[msimberg]

Thanks @aurianer for looking into this! I think we should test this with +stdexec since that is the use case for this and I think enabling that will break in CI. Could explore a bit how this fails with stdexec enabled so that we can see how to tackle this best? In particular I'm worried about the feature tests being insufficient if we start allowing different standard versions.

This PR is in general lower priority until we've tested the CPU-only configurations in DLA-Future though.

[msimberg]

What was the problem with 10.0.0?

[aurianer]

https://gist.githubusercontent.com/aurianer/ac750bcf87d7d71846864ae16a5f5d00/raw/b91eeef989c28a4c659a7bed5d3e96b2c650f357/compiling_cuda_sender_test_stdexec_fmt10

[msimberg]

Thanks. During compilation of which file does that happen?

We definitely have that covered here:

pika/libs/pika/logging/include/pika/logging/level.hpp

Lines 61 to 69 in 41b4abb

	template <>
	struct fmt::formatter<pika::util::logging::level> : fmt::formatter<std::string>
	{
	template <typename FormatContext>
	auto format(pika::util::logging::level const& value, FormatContext& ctx)
	{
	return fmt::formatter<std::string>::format(pika::util::logging::levelname(value), ctx);
	}
	};

. But this may be one (of many) problems that we get from allowing different standards. I'd like to see how badly other things break from this as well before we decide what to do here...

[aurianer]

Many of the cuda files, the error I pasted is for cuda_sender_test though, will try to add the GPU stdexec and then see what's happening

[sonarcloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
16 Code Smells

No Coverage information
0.0% Duplication

Catch issues before they fail your Quality Gate with our IDE extension SonarLint

[msimberg]

You might want to set

Suggested change

	configuration_skip_pr="true"
	configuration_skip_pr="false"

for now if you want to test this in CI. In this case it may be easier to just test it manually though.

[msimberg]

@aurianer should we abandon this now that we've got DLA-Future compiling with C++20?