Adding clangd

[Diyou]

Can we have clangd shipped alongside clang++ etc. ? Module files seem to be very finicky with differing versions.

For example if I wouldn't use the NDK's provided clangd it'd break with:

Module file 'CMakeFiles/SDLTemplate.dir/App.pcm' uses an older format that is no longer supported

or with emscripten:

Module file 'CMakeFiles/SDLTemplate.dir/App.pcm' uses a newer format that cannot be read

[sbc100]

Seems reasonable to ship yes.

Likely we would need to add to the list here: https://chromium.googlesource.com/emscripten-releases/+/refs/heads/main/src/build.py#669. @dschuff ?

[dschuff]

Yeah we can do that if it would be useful. @Diyou I'm curious how you are using clangd? Are there other clang tools that are needed or would be useful?

[Diyou]

@dschuff For vscode I'd use the clangd extension and let cmake configure the settings.json to point to the clangd executable.

When installing emscripten on arch for example the binaries(clang clang++ etc.) would be in a completely different relative location compared to emsdk which makes it harder to figure out.

Using clang/clang++ instead of emcc/em++ in the .clangd file for the compiler setting could be relevant so having them in an inferable location would be very helpful.

[dschuff]

I'm not quite sure I understand whether you are asking for something in particular beyond adding clangd to our build? Regarding your last paragraph, I seem to recall we had a similar discussion around clang-scan-deps and we ended up making an 'emscan-deps' wrapper for it to go along with emcc etc. We could probably do that for clangd. How does CMake configure the clangd path?

[dschuff]

btw, I suspect Arch is not using our build.py script to build LLVM or our emsdk binary package, so if that's what you're using the emsdk change probably wouldn't help and you'd need to get clangd built in the Arch package.

[Diyou]

How does CMake configure the clangd path?

I'm using a toolchain file that infers the compiler path and edits the settings.json like so: vscode/Config.cmake

I'm not quite sure I understand whether you are asking for something in particular beyond adding clangd to our build?

I don't know to what degree emscripten's flags would be relevant for the parsing. Just stripping them away might not be desirable but necessary to prevent parsing errors. In the past I'd use something likes this to curb some of the issues in the .clangd file:

CompileFlags:
  Remove: [
    -sUSE*
  ] 

[sbc100]

I'm using a toolchain file that infers the compiler path and edits the settings.json like so: vscode/Config.cmake

The code linked above seems to assume that clangd is installed in the same directory as the compiler. That is not the case for emcc which is not installed in the same directory and the llvm tools.

[Diyou]

There is also clang --print-prog-name=clangd that could be used. emcc would need to handle this though.

[sbc100]

The --print-prog-name argument should fixed in emscripten-core/emscripten#25547