[feature] can't specify c++20 with meson generator

[lukester1975]

What is your suggestion?

/std:c++20 is supported by cl since VS 2019 16.11 :

The /std:c++20 option enables C++20 standard-specific features and behavior. Available starting in Visual Studio 2019 version 16.11

and clang-cl since 13.

c++latest is far from ideal as it turns on 23 features (and generates a ton of deprecation warnings). An additional consideration is that only meson 1.0.1 supports c++20 for clang-cl. So ultimately

_vs_cppstd_map = {
    '14': "vc++14",
    '17': "vc++17",
    '20': "vc++latest"
}

is somewhat simplistic, as ideally it's a function of compiler, compiler version and meson version... But maybe a trivial change to vc++20 is pragmatic?

Thanks

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @lukester1975

Thanks for your report

I think that mapping do not affect clang compiler and only msvc compiler:

    if compiler == "msvc":
        return _vs_cppstd_map.get(cppstd)

But '20': "c++20", 'gnu20': "gnu++20" would be valid for clang compiler.

[lukester1975]

Well ... I'd say yes and no :) I really meant the clang-cl driver, rather than clang, but I was going to open an issue about that separately - getting conan to actually use the clang-cl driver (i.e. via the ClangCL toolset) seems difficult, but I've not read all the relevant issues on that subject yet (there are quite a few!)... That said I have a 3 line mod (2 in profile, 1 in settings.yml) that makes it "just work". I really don't want the clang driver...

But as for the subject of this issue, yeah proper cl + /std:c++20 support is the concern, I just mention meson 1.0.1 and clang-cl here for completeness. Ultimately the mapping should be a function of compiler version and meson version, I suppose. But maybe not worth the effort?

Thanks

[memsharded]

You might want to read https://blog.conan.io/2022/10/13/Different-flavors-Clang-compiler-Windows.html.

For Conan the clang-cl is a driver for clang compiler, so the underlying compiler is clang and the Conan setting should be compiler=clang. Using the Visual Studio generator will automatically define the ClangCL toolset for you.

[lukester1975]

I think I'm derailing the subject of my own issue! Yeah I've seen that but it's still not quite there for me without some extra work. The meson native file gets:

[binaries]
c = 'clang'
cpp = 'clang++'

Which meson isn't happy with with the vs backend (fails setup); should both be clang-cl (and really with ninja, even though that passed the setup step).

Adding to the profile:

[buildenv]
CC=clang-cl
CXX=clang-cl

Seems OK but should surely be automatic? I guess

https://github.com/conan-io/conan/blob/release/2.0/conan/tools/meson/toolchain.py#L170-L178

could be a bit smarter to make it bullet proof? Anyway, I could well be missing something obvious so wasn't going to mention it to avoid looking silly before I'd looked into it further :) Oh well.

But yeah if even with targeting clang-cl the clang style std options are used, then I guess the meson 1.0.1 thing isn't relevant.

Cheers

[memsharded]

You are right that there are some cases, specifically with other build systems that might need some extra tuning, and we are aware that specifically using the clang-cl driver might need further inputs or conf from Conan to be able to configure that automatically. The above comment with ClangCL toolset from VS only applies when using the Visual Studio CMake generator, not with Meson indeed.

In the meantime, what you are doing with [buildenv] seems a reasonable workaround.

We would need to consider this a bit from perspective, not only for Meson, but potentially other tools too. Annotating this for investigation.

[lukester1975]

OK sounds good, thanks.

How about the c++latest thing? I don't mind having a go to help out if I'm told what approach might be best. OTTOMH

1. Change mapping of 20 to vc++20 and maybe add 23 -> vc++latest?
2. Add compiler version to to_cppstd_flag
3. Add compiler and meson version to to_cppstd_flag

[memsharded]

Sure that would be great.

There is already some per-compiler definition of what cppstd are supported in conan.tools.build.cppstd.py, not sure if that could be leveraged somehow in the Meson helper.

Indeed if meson now allows other cppstd definition, it would be good to updated (still, it seems only for msvc compiler)

For processing the compiler version, there is also some existing code in conan.tools.build.flags.py like _cppstd_msvc(). Maybe it is possible to also leverage this, and adapt to Meson, than duplicating all of that.

We would prefer not having to parameterize the Meson version, there is no input configuration for it. We don't even model the CMake version, and work with a baseline of CMake 3.15, and some features we just assume a certain version. But we don't do conditionals based on the CMake version to do different things. That makes things too complicated and difficult to maintain.

[lukester1975]

OK here's an initial attempt: lukester1975@3b95565 I'm not really a python person so please be gentle 😀 Should I move this to a PR?

• I had a quick look at cppstd.py but it's not really a help as is. Probably a master mapping of cppstd<>compiler versions would be useful, and it and the meson part could use that too.

• Also made the change to use c++20 rather than c++latest with compiler version 192 (so assuming VS2019 16.11 or later). But maybe that's too dramatic a change?

• Similarly, maybe c++23 -> c++latest is a bit unrealistic with VS2019. It has some support AIUI.

Thanks

[memsharded]

Hi @lukester1975

Yes, did a quick review, added a comment, but I'd say it looks good, I think it can be moved to a PR, many thanks!

[lukester1975]

FYI I noticed a couple more cl vs. clang-cl inconsistencies. Not sure if they are known/expected, but in case not:

1. cpp_std in the generated meson ini file will not have the v prefix with clang-cl. Looking at the meson code, I think they are attempting to allow permissive mode with vc++X and non-permissive with plain c++X (which doesn't really work since the default /permissive behaviour change mid VS2019 release with >= c++20, so both are now non-permissive...). Anyway, ideally conan should be generating the same for both cl and clang-cl, I imagine? I might open an issue on meson too.

2. settings.compiler.runtime_type doesn't get a default based off of build_type:
   

   conan/conans/client/profile_loader.py

   Lines 31 to 35 in ba12bd1

   	def profile_plugin(profile):
   	settings = profile.settings
   	if settings.get("compiler") == "msvc" and settings.get("compiler.runtime"):
   	if settings.get("compiler.runtime_type") is None:
   	runtime = "Debug" if settings.get("build_type") == "Debug" else "Release"

   
   So has to be specified in the profile.

3. The meson code would also need a tweak, I think:
   

   conan/conan/tools/meson/toolchain.py

   Lines 128 to 130 in ba12bd1

   	if compiler == "msvc":
   	vscrt = msvc_runtime_flag(self._conanfile)
   	self._b_vscrt = str(vscrt).lower()

   
   So it's never populated in the meson native file, but meson default is from_buildtype so it kinda works (unless you want a static runtime...). if compiler in ("msvc", "clang"): doesn't seem a good idea, but it wasn't obvious how to know it's targeting clang-cl at that point (I'm probably missing something, I haven't poked around in the conan code that much!).

Speaking of which, whilst I was looking around to see how cl vs clang-cl is distinguished elsewhere, I noticed this:

conan/conan/tools/cmake/toolchain/blocks.py

Lines 83 to 104 in ba12bd1

	if compiler not in ("msvc", "clang", "intel-cc"):
	return
	runtime = settings.get_safe("compiler.runtime")
	if runtime is None:
	return
	config_dict = {}
	if os.path.exists(CONAN_TOOLCHAIN_FILENAME):
	existing_include = load(CONAN_TOOLCHAIN_FILENAME)
	msvc_runtime_value = re.search(r"set\(CMAKE_MSVC_RUNTIME_LIBRARY \"([^)]*)\"\)",
	existing_include)
	if msvc_runtime_value:
	capture = msvc_runtime_value.group(1)
	matches = re.findall(r"\$<\$<CONFIG:([A-Za-z]*)>:([A-Za-z]*)>", capture)
	config_dict = dict(matches)
	build_type = settings.get_safe("build_type") # FIXME: change for configuration
	if build_type is None:
	return None
	if compiler == "msvc" or compiler == "intel-cc" or compiler == "clang":

Could bin the if on 104 presumably?

Thanks

[memsharded]

FYI I noticed a couple more cl vs. clang-cl inconsistencies. Not sure if they are known/expected, but in case not:

Thanks for noticing. Indeed there are a couple of details to polish regarding the clang and clang-cl distinction (fyi, some recent blog on this https://blog.conan.io/2022/10/13/Different-flavors-Clang-compiler-Windows.html)

I'd say focus this on getting the meson for msvc (cl) compiler right, and than address clang in other PRs later. It might need some discussion first, using the above blog as starting point, not a top priority at the moment, but something we would definitely like to improve.