Feature: add msstl to the default settings for Clang on Windows (clang-cl)

[SSE4]

related to the #1839

Changelog: Feature: add msstl to the default settings for Clang on Windows (clang-cl)
Docs: https://github.com/conan-io/docs/pull/XXXX

• Refer to the issue that supports this Pull Request.
• If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
• I've read the Contributing guide.
• I've followed the PEP8 style guides for Python code.
• I've opened another PR in the Conan docs repo to the develop branch, documenting this one.

^{Note: By default this PR will skip the slower tests and will use a limited set of python versions. Check here how to increase the testing level by writing some tags in the current PR body text.}

default settings.yml have only libstdc++ and libc++ as possible standard library implementations for Clang. Clang on Windows (aka clang-cl) uses neither of these - it uses standard library implementation from the Microsoft Visual Studio.
this setting will result in-stdlib argument passed to the compiler, as it's incorrect and unsupported.

[lasote]

There is no other clang on windows different from this one, not using msstl? What is the relationship/difference against using this or the visual studio toolset? Maybe we should have clear enough the refactor to the visual studio settings model (IDE vs compiler) before? or not really?

[lasote]

These are the "old" settings from the previous version. Doesn't make sense to change them here.

[SSE4]

that's the good question, how to model it, currently, as there are at least 3 concurrent ways, from that I know:

• using Visual Studio compiler + LLVM toolset. probably, very limited only to MSBuild and CMake based projects with Visual Studio generator, as toolset concept is Visual Studio specific. also, for me it appears to be conceptually incorrect, as compiler setting value doesn't represent the reality.
• using clang as compiler and specifying CC/CXX to clang-cl.exe
• using clang as compiler and specifying CC/CXX to clang.exe/clang++.exe

I've seen users doing all 3 of these, and they all actually work.

for clang other than using msstl, I've seen some articles which had clang installed in MinGW and used libstdc++ as standard library. I've never tried it, but it exists. also, I believe libc++ will be ported to Windows, eventually.

[memsharded]

I cannot find any reference to such msstl library in the internet. Any pointer please?

[SSE4]

this is just an abbreviation I've used to refer Microsoft STL. it doesn't translate literally to the -stdlib=msstl or something like that.
in general, it refers to the usage to the C++ standard library shipped with Microsoft Visual Studio.
do you have a suggestion for better naming?

[memsharded]

But is this the same MSVCRT or LIBCMT that is used for Msft compiler?

[SSE4]

MSVCRT/LIBCMT is C runtime library, not C++ one, but yes, it uses the same as MSVC

[memsharded]

Yes, sorry, I meant MSVCPRT and LIBCPMT. So the clang settings will also need to specify the static/shared runtime? That is my concern.

[SSE4]

yep, it has the same static/shared runtime support (/MD, /MDd, /MT, /MTd).
and I would expect clang to have the same compile.runtime sub-setting as Visual Studio currently has.
but that's an another addition, besides how to model compiler.libcxx.

[jgsogo]

I think that this PR tries to workaround something that is missing in the settings model. Adding msstl to the clang.libcxx works because Conan has an if/else defaulting to the empty string if the libcxx value doesn't match a known one.

This issue belongs to the "refactor settings model" project we should open, gather there all the related issues and think about the model we need for 2.0 and how to backport it to the current Conan version.

[lasote]

Yes, I agree something is not clear here. Maybe it could make more sense to have a libcxx as a first level setting. Or a subsetting of os? Let's create the project "refactor settings model"