Added CUDA generator expressions around MSVC compile options to fix transitive include in CUDA builds.

[Cazadorro]

📋 Pull Request Description

If one compiles any targets on windows with MSVC that transitively has a target_link_library dependency on mp-units::core, the corresponding target will fail to generate because NVCC will see extra unknown flags (ie /utf-8) that it doesn't know how to deal with. In practice users end up with errors like:

nvcc fatal : Don't know what to do with 'C:/utf-8'

This change adds generator expressions to fix this that only popup when using CUDA and properly forward the compile options to MSVC through NVCC.

Type of Change

• 🐛 Bug fix (non-breaking change which fixes an issue)
• ✨ New feature (non-breaking change which adds functionality)
• 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
• 📚 Documentation update
• 🔧 Build system / CI changes
• 🧪 Test improvements
• ♻️ Code refactoring
• 🎨 Code style improvements

🔗 Related Issues

📝 Changes Made

This change adds "$<$<COMPILE_LANGUAGE:CUDA>:--compiler-options=>" to each of the three compile options used in core when using MSVC, /utf-8, /kernel and /wd5244. This generator expression will expand to "--compiler-options=/flag" when in the CUDA language mode, but will simply expand to "/flag" when this is not the case. Thus this change should not be a breaking change for anyone not using CUDA and on MSVC (and touches nothing at all when not using MSVC). This effectively passes these flags through NVCC to MSVC (the host compiler).

🌟 Additional Context

AFAIK this flag-passing issue with CUDA isn't an issue on linux using GCC style command line arguments, and since no one should be building the unit-tests with NVCC, this is not needed test/runtime. Note all future MSVC flags that are used on mp-units external library targets should also follow this pattern. Note also that if you have a long list of MSVC compiler flags you should still wrap each one like was done here because you will have to manually parse flags and figure out how to deal with ',' flags and other edge cases, which don't happen if you just use $<$<COMPILE_LANGUAGE:CUDA>:--compiler-options=> for each flag

Additionally, I see similar arguments passed to conan. I'm not familiar with conan, so I don't feel like I can fix this issue there, so if a similar problem persists over there because of how conan sets up it's own flags for MSVC, I won't be able to fix them.

✅ Checklist

• I have read the Contributing Guidelines
• I have commented my code, particularly in hard-to-understand areas
• I have added tests that prove my fix is effective or that my feature works: This requires adding NVCC to the CI pipeline with MSVC as the host. Currently, while the preview build of MSVC can compile 2.5.0, MSVC is currently incapable of compiling master, and likely won't be able to until after 2.6.0. However, since this happens at CMake configure time, and not building the library itself, it might be possible to only trigger the cmake configuration with this combo in the CI to test this.
• I have updated the project's documentation to cover the modified or new functionality
  (if this change affects user-facing features)

---

By submitting this pull request, I confirm that my contribution is made under the terms
of the project's MIT license.

[Cazadorro]

I see a formatting thing failed, but I don't see the output of it, so I'm not sure what went wrong in the formatting I'm also not sure what tool I should be running to format the file.

[mpusz]

I see a formatting thing failed, but I don't see the output of it, so I'm not sure what went wrong in the formatting I'm also not sure what tool I should be running to format the file.

https://github.com/mpusz/mp-units?tab=contributing-ov-file#unified-code-formatting

We also need to somehow cover Conan:

mp-units/conanfile.py

Lines 371 to 372 in f0a0b97

	if compiler == "msvc":
	self.cpp_info.components["core"].cxxflags.append("/utf-8")

[Cazadorro]

I see a formatting thing failed, but I don't see the output of it, so I'm not sure what went wrong in the formatting I'm also not sure what tool I should be running to format the file.

https://github.com/mpusz/mp-units?tab=contributing-ov-file#unified-code-formatting

We also need to somehow cover Conan:

mp-units/conanfile.py

Lines 371 to 372 in f0a0b97

	if compiler == "msvc":
	self.cpp_info.components["core"].cxxflags.append("/utf-8")

I'm not sure how conan works so I'm a bit confused by why this is even happening. Isn't this project still consumed as cmake under conan? Why does conan even apply this flag in the first place if the CMake already handles this? My first impression is that since this isn't a configuration option and very much is a build system thing, Conan, when being used with a properly configured cmake project (like mp-units), I don't believe should even be touching this kind of stuff.

[Cazadorro]

Looking into this more, is conan even able to express the same kind of semantics here that CMake is? The problem is that you can't just check if CUDA exists/is being used, because this applies separately to NVCC before host compilation with MSVC (you actually need NVCC and the host compiler to run on the code base when compiling with CUDA, and if you only pass in --compiler-options=/flag, MSVC will complain) , hence why a generator expression is necessary.

[mpusz]

@memsharded, could you please take a look at that? Is there anything we can do to make Conan generate files similar to those generated by CMake for those CMake changes?

[memsharded]

Hi all,

We recently introduced a flags plugin in Conan to be able to handle cases like this.

The problem is that recipes that define something like:

if compiler == "msvc": 
     self.cpp_info.components["core"].cxxflags.append("/utf-8") 

will inject into the consumers that use this recipe the /utf-8 flag, even if the consumer is not using msvc compiler but a different one, that will not understand the flags.

If one compiles any targets on windows with MSVC that transitively has a target_link_library dependency on mp-units::core, the corresponding target will fail to generate because NVCC will see extra unknown flags (ie /utf-8) that it doesn't know how to deal with. In practice users end up with errors like:

Can you please detail a bit more about the commands you are using to consume the library? Are you using conan install, and if so with what profiles?

The plugin that was added is described in https://docs.conan.io/2/reference/extensions/compiler_flags_plugin.html, and allows to filter or modify flags as desired.

[Cazadorro]

Hi all,

We recently introduced a flags plugin in Conan to be able to handle cases like this.

The problem is that recipes that define something like:

if compiler == "msvc": 
     self.cpp_info.components["core"].cxxflags.append("/utf-8") 

will inject into the consumers that use this recipe the /utf-8 flag, even if the consumer is not using msvc compiler but a different one, that will not understand the flags.

If one compiles any targets on windows with MSVC that transitively has a target_link_library dependency on mp-units::core, the corresponding target will fail to generate because NVCC will see extra unknown flags (ie /utf-8) that it doesn't know how to deal with. In practice users end up with errors like:

Can you please detail a bit more about the commands you are using to consume the library? Are you using conan install, and if so with what profiles?

The plugin that was added is described in https://docs.conan.io/2/reference/extensions/compiler_flags_plugin.html, and allows to filter or modify flags as desired.

We don't use conan, this fix fixes things for VCPKG and any one just doing a normal CMake install. The problem is that someone else needs to handle the Conan part since I don't use it.