Add clangd wrapper script

[septatrix]

It might also make sense to add the following content to suppress warnings which appear because the compile_commands.json is based on GCC and not Clang

# See https://github.com/xuwd1/vscode-kernelmod-guide/blob/master/.clangd
CompileFlags:
  Add: -Wno-unknown-warning-option
  Remove: [--hack*, --ibt,--orc,--retpoline,--rethunk,--sls,--static-call,--uaccess,--link,--module,-mpreferred-stack*,-mindirect-branch*,-fno-allow-store*,-fconserve-stack,-mrecord-mcount,-ftrivial-auto*]

PS: Some way of getting .clang-tidy in there (or simply referring to the default one provided by the kernel) would also be great

[septatrix]

Apart from two small changes where I had to hardcode something in the mkosi.clangd file this is now the setup I got working this evening. I also opened systemd/mkosi#3206 which I think would allow us to make this a lot cleaner and avoid some of the current problems

[septatrix]

PS: Some way of getting .clang-tidy in there (or simply referring to the default one provided by the kernel) would also be great

I now got .clang-tidy working (simply copy the one from the kernel tree to the working directory beforehand) but that moves it to the host and thus always results in a dirty git state... It seems like it should also be possible to pick it up based on the file being edited (clangd/vscode-clangd#367) but I am not sure if path-mappings interfere with that or if simply did not put it in the correct place yet.

---

PS: Well, no it is no longer working. I am not really sure what I changed - maybe it was some fluke due to leftover files from a previous run

[septatrix]

Rebased to use systemd/mkosi#3216 which makes this a decent bit cleaner as the other build scripts no longer get in our way

[DaanDeMeyer]

We should parse the first argument as the source dir to run clangd in and cd into it before invoking clangd

[septatrix]

And omit the --compile-commands-dir then such that clangd picks it up from the current dir? I am not sure if that really works as well as we hope it does. It also means that we would need to put the compile DB of the kernel under the kernel sources which makes it impossible to reuse the same kernel source for multiple mkosi-kernel projects.

[DaanDeMeyer]

This should map to $BUILDDIR/$1 if we pass the source dir to run clangd in as the first argument

[DaanDeMeyer]

We should pass this when invoking mkosi with this script as the beginning. You can map the current working directory to /work/src/$1 if the source dir is passed as the first argument

[septatrix]

I see no reason why we should simply map all dirs for which we have information available. Only mapping a single one will also be difficult because we do not know which of the BuildSources it is. And passing it via CLI does not work because we need to also know the path outside the build sandbox, not only inside. For systemd this works because there is only a single build source usually configured and that is generally $PWD on the host

[DaanDeMeyer]

@septatrix I would make the assumption that $PWD when mkosi.clangd is invoked outside of mkosi is the path outside the sandbox. And the target path inside the sandbox is what's passed in as $1

[septatrix]

But the path inside the sandbox will always be one of BuildSources, same for $PWD - except for dubious cases where one uses mkosi-kernel as a clangd provider for a different source tree which I think we do not need to support.
Unless I am missing something the current jq filter covers a subset of all mappins which make sense by manually passing them - it just does it automatically for you and for all of them

[DaanDeMeyer]

We shouldn't assume this script is invoked from the mkosi-kernel source directory. So this should use the BASH_SOURCE magic to figure out the directory this script is located in and then pass that to --directory with ../.. to make sure we run mkosi in the right directory

[septatrix]

No we indeed shouldn't and that's also why I resolve the path to the build script below. However, I would assume it's more likely that the user wants mkosi to scan the config from the current dir than from mkosi-kernel (e.g. when including the latter)?

[DaanDeMeyer]

I think that's the more unlikely scenario.

The more likely scenario is that a user has a separate kernel tree open in their editor and wants to run clangd from mkosi-kernel within that editor workspace. And that means $PWD will not be the mkosi-kernel repository and instead we should chdir() to it with --directory

[septatrix]

In that case they can simply create a dummy mkosi.conf with an include statement for mkosi-kernel or prepend env --chdir ... to the invocation of the clangd wrapper script. If we always chdir to the mkosi-kernel directory we would make it completely impossible to use mkosi-kernel with Include= whereas the current state makes that trivial all while your scenario is still quite simple

[septatrix]

Regarding .clang-format I seem to have figured out what's going on: The --path-mapping are not applied during lookup of the format config. Thus clangd searches the tree upwards from /home/$USER/.../kernel. The only solution I see so far is putting the .clang-format file at the root - and reporting this upstream

[septatrix]

I have now put the compile commands DB under $BUILDDIR which makes it easier to use when multiple projects share the same build source with different localversions but sadly makes the clangd wrapper script a bit more convoluted because we have to determine the $BUILDDIR there now