What is your suggestion?

In further exploration of compatibility handling, I've been able to get builds with Clang on Windows using MSVC built packages. One issue that cropped up was compatibility for using packages which set cxxflags within cpp_info. This initially limited our flexibility in using compatibility with Clang on Windows.

The particular recipe where this cropped up is Qt, which quite reasonably sets -permissive- and -Zc:__cplusplus cxxflags when building the package with MSVC. That's sensible on the recipe side since it's guarded by is_msvc at recipe time. However, at compatibility consumption time with Clang it causes a failure due to not being recognized arguments.

This may well be pushing the boundary of compatibility, but it's a definite issue effecting us. For now it's sufficient for us in our internal recipe copy to disable setting of cxxflags, relying on the product build system to ensure the same effective flags are in place (which they already are). I'm not sure what a more general solution would look like; my prevailing thought is to allow setting cxxflags in a compiler-specific manner. In this context, ideally that'd be required, but for compatibility can't be. However it would provide a path by which a recipe could be more declarative, with some recipes only ever setting flags for a compiler at a time, and leave it up to the compatibility handling to account for the gap if needed. Over time it would also allow recipes which wish to offer richer compatibility handling to do so, initially by making all cxxflags compiler specific, and possibly even similar options for multiple compilers. That would add significant complexity when also considering all of compilers, versions, and platforms though.

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide