[cmake] Add emscan-deps tool to enable C++20

[sbc100]

This is wrapper around clang-scan-deps. Currently this is just enough to make C++20 work under cmake. We don't currently have any actaully tests of C++20 modules.

See: #21042
Fixes: #21866 #22305

[dschuff]

Is it actually necessary to have the em-foo wrapper? Is there some reason we can't just tell CMake the location of the clang-scan-deps tool directly?

[sbc100]

Is it actually necessary to have the em-foo wrapper? Is there some reason we can't just tell CMake the location of the clang-scan-deps tool directly?

The problem with that is that I can't find a way to make clang-scan-deps know about the emscripten include paths in that case. Perhaps there is some way to make it work, but I don't really know how clang-scan-deps works.

[dschuff]

Is it actually necessary to have the em-foo wrapper? Is there some reason we can't just tell CMake the location of the clang-scan-deps tool directly?

The problem with that is that I can't find a way to make clang-scan-deps know about the emscripten include paths in that case. Perhaps there is some way to make it work, but I don't really know how clang-scan-deps works.

I've been wondering for a while if it made sense to just teach clang directly about the emscripten include paths. We already have an emscripten triple. I would imagine clang-scan-deps just uses the same logic, but I also don't really know how clang-scan-deps works.

[sbc100]

Is it actually necessary to have the em-foo wrapper? Is there some reason we can't just tell CMake the location of the clang-scan-deps tool directly?

The problem with that is that I can't find a way to make clang-scan-deps know about the emscripten include paths in that case. Perhaps there is some way to make it work, but I don't really know how clang-scan-deps works.

I've been wondering for a while if it made sense to just teach clang directly about the emscripten include paths. We already have an emscripten triple. I would imagine clang-scan-deps just uses the same logic, but I also don't really know how clang-scan-deps works.

But how would clang know where the emscripten sysroot is without being told like this in the wrapper?

[dschuff]

But how would clang know where the emscripten sysroot is without being told like this in the wrapper?

I think it might make sense for CMake to pass the sysroot and triple flags. This solution of course wouldn't generalize to other build systems, and we might want to keep passing those in emcc, but I think CMake still passes those flags in some other contexts so it wouldn't be too weird. That might be enough to make scan-deps work.

[sbc100]

But how would clang know where the emscripten sysroot is without being told like this in the wrapper?

I think it might make sense for CMake to pass the sysroot and triple flags. This solution of course wouldn't generalize to other build systems, and we might want to keep passing those in emcc, but I think CMake still passes those flags in some other contexts so it wouldn't be too weird. That might be enough to make scan-deps work.

I don't think cmake has enough information to figure that stuff out. It doesn't know where the sysroot it is. It could probably run emcc to figure that out? But also I'm not sure it is able to pass cflags only to scan deps do it would end up passing them everywhere.. which would be redundant. emcc doesn't need a sysroot flag so why both to calculate one and pass it in?

Ultimately I think we will need to figure out a better / deeper way to integrate with scan-deps, but this approach seems like a reasonable step one.

[dschuff]

Actually I meant having CMake have the information about the sysroot in our toolchain file (since that already has alll the special knowledge about emscripten/emsdk) do it for both clang and scan-deps. Then if we wanted to, we could remove that from emcc and/or be one step closer to not needing emcc at all at compile time. But yeah in the near term it would be redundant. I'm kind of ok with this as a short-term solution, mostly I'm just noting that it goes the opposite direction we want to go in long term.

[connorjclark]

FYI the "Fixes" github reference is wrong, it should probably be #21866

Any chance this could land as a temporary fix for newer cmake? :)

[jpvanoosten]

I'm also hoping to see this short-term fix get merged soon ;)

Thanks for the effort so far @sbc100 and @dschuff and @kripken !

[jpvanoosten]

Any news about this?

[leandro-benedet-garcia]

Hello, just wanted to know if there is anything preventing this from getting merged.

[dsamo]

Hello, will there be any progress on this?

[eliemichel]

While waiting for this to land, here is a template repo that imports the bits of this PR locally so that one can build C++20 without the need to upgrade emscripten: https://github.com/eliemichel/cpp20-cmake-emscripten-template

[dschuff]

@sbc100 I think we still want this. IIRC it appeared to be working but there was a failure in the CMake tests that we never debugged. This has been an issue for a long time, I think we should fix it soon.

[sbc100]

Sorry, I did an accidental mass-closing. Re-opening them all now.