clangd ignores `--compile-commands-dir=<string>` for relative paths in compile_commands.json

[Febbe]

Please describe the problem:

When executing clangd in a directory distinct to the compile-commands-dir nearly all relative paths in the compile_commands.json can't be resolved, because clangd tries to resolve them relative to the clangd directory, not the directory of the file, the paths are from.

Logs No crash logs System information No special system informations

Output of clangd --version: clangd version 12.0.1 (https://github.com/llvm/llvm-project fed41342a82f5a3a9201819a82bf7a48313e296b)

Editor/LSP plugin: ms visual studio code - clangd plugin

Operating system: Windows 10

[HighCommander4]

nearly all relative paths in the compile_commands.json can't be resolved

Which paths in your compile_commands.json are relative?

My reading is of the compilation database spec is that paths in command and file are allowed to be relative, and if so they are interpreted relative to directory.

The spec does not say anything about directory itself being relative; I would consider that an unsupported configuration.

[kadircet]

Handling of compile_commands.json is done at a higher level than clangd and shared amongst all clang-based tools. That layer assumes that the "directory" field will always be absolute. Even though it is not explicit in the spec as it could be, it says that the directory field is The working directory of the compilation. also it goes on like All paths specified in the command or file fields must be either absolute or relative to this directory.. I don't think it is possible for a relative directory to be relative to a non-absolute one, or working directory itself to be relative.

Hence when you have a relative directory in your compilation database, most tools will interpret it as relative to whatever the current working directory in the environment is.

That being said, I am not sure there are viable solutions here. Surely we can try to interpret everything relative to the whatever directory was specified in compile-commands-dir option, but:

• Most users don't really specify it
• There's no good way to communicate it to the lower layer compilation database implementation
• It'll create a discrepancy with other clang-based tools
• It's too rare to justify all of this extra effort needed

---

Can you tell us more about your use case so we can try to figure out if it's symptom of a bigger problem? Otherwise as I mentioned I don't think there's much we can do.

[Febbe]

Hadn't much time, but here is what I found out so far:

• The compile_commands.json is created by cmake used with the Ninja generator.

• The working directory of cmake is in ${project-dir}/build/.

• The working directory in the file in is indeed correct, and if everything would work, the missing include should be found.

• The include is located in -IC:\\my-qt-project\\build\\gui_desktop\\gui_desktop_autogen\\include

• The include is created by qt_moc.

• here the generated section in the file, which does not work somehow:

  {
  "directory": "C:/my-qt-project/build", 
  "command": "C:\\PROGRA~2\\MICROS~4\\2019\\COMMUN~1\\VC\\Tools\\MSVC\\1429~1.301\\bin\\Hostx64\\x64\\cl.exe /nologo /TP -DASIO_STANDALONE -DBOOST_DATE_TIME_NO_LIB -DBOOST_REGEX_NO_LIB -DGTEST_LANGUAGE_CXX11 -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_OPENGLWIDGETS_LIB -DQT_OPENGL_LIB -DQT_WIDGETS_LIB -DSPDLOG_COMPILED_LIB -DUNICODE -DWIN32 -DWIN64 -D_ENABLE_EXTENDED_ALIGNED_STORAGE -D_UNICODE -D_WIN64 -Dkiss_fft_scalar=double -IC:\\my-qt-project\\build\\gui_desktop -IC:\\my-qt-project\\project\\gui_desktop -IC:\\my-qt-project\\build\\gui_desktop\\gui_desktop_autogen\\include -IC:\\my-qt-project\\build\\generated -IC:\\my-qt-project\\project\\core\\include -IC:\\my-qt-project\\project\\dapi\\include -IC:\\my-qt-project\\project\\gui_desktop\\include -IC:\\my-qt-project\\project\\license_base\\include -IC:\\my-qt-project\\project\\license_client\\include -IC:\\my-qt-project\\project\\license_server\\include -IC:\\my-qt-project\\project\\util\\include -IC:\\my-qt-project\\project\\gui_desktop\\res -IC:\\my-qt-project\\project\\gui_desktop\\src -IC:\\my-qt-project\\dependencies\\spdlog\\include -IC:\\my-qt-project\\dependencies\\asio\\asio\\asio\\include -IC:\\my-qt-project\\dependencies\\OpenMesh\\src\\OpenMesh\\Core\\..\\.. -IC:\\my-qt-project\\dependencies\\OpenMesh\\src\\OpenMesh\\Tools\\..\\.. -IC:\\my-qt-project\\dependencies\\kissfft\\kissfft -IC:\\local\\boost_1_76_0 -IC:\\Qt\\6.2.0\\msvc2019_64\\include\\QtCore -IC:\\Qt\\6.2.0\\msvc2019_64\\include -IC:\\Qt\\6.2.0\\msvc2019_64\\mkspecs\\win32-msvc -IC:\\Qt\\6.2.0\\msvc2019_64\\include\\QtWidgets -IC:\\Qt\\6.2.0\\msvc2019_64\\include\\QtGui -IC:\\Qt\\6.2.0\\msvc2019_64\\include\\QtOpenGLWidgets -IC:\\Qt\\6.2.0\\msvc2019_64\\include\\QtOpenGL -IC:\\my-qt-project\\dependencies\\outcome\\include -IC:\\Qt\\6.2.0\\msvc2019_64\\include\\QtNetwork -IC:\\my-qt-project\\dependencies\\cmake\\..\\eigen -IC:\\my-qt-project\\dependencies\\glm /DWIN32 /D_WINDOWS /GR /EHsc -MDd /D_USE_MATH_DEFINES -Zc:__cplusplus -permissive- -utf-8 /D_USE_MATH_DEFINES /DNOMINMAX /DWIN32_LEAN_AND_MEAN /D_WIN32_WINNT=0x0601 /DBOOST_THREAD_USE_LIB /W3 /WX -std:c++latest /YuC:/my-qt-project/build/gui_desktop/CMakeFiles/gui_desktop.dir/cmake_pch.hxx /FpC:/my-qt-project/build/gui_desktop/CMakeFiles/gui_desktop.dir/./cmake_pch.cxx.pch /FIC:/my-qt-project/build/gui_desktop/CMakeFiles/gui_desktop.dir/cmake_pch.hxx /Fogui_desktop\\CMakeFiles\\gui_desktop.dir\\src\\widgets\\mainwindow.cpp.obj /FdTARGET_COMPILE_PDB /FS -c C:\\my-qt-project\\project\\gui_desktop\\src\\widgets\\mainwindow.cpp", 
  "file": "C:\\my-qt-project\\project\\gui_desktop\\src\\widgets\\mainwindow.cpp" 
  },

[HighCommander4]

I don't see any relative paths in that entry... so whatever the problem is, it's not related to relative paths.

[HighCommander4]

A good next step to investigate your issue would be to share some clangd logs.

[Febbe]

There were some previously, but I updated cmake ninja and msvc. So this obviously means, that the problem is somewhere else.

[Febbe]

Ok seems like, there was a name clash between 2 targets, and clang handled them wrongly(?):

• Both targets had the files mainwindow.h, mainwindow.cpp and mainwindow.ui
• One target was disabled, so the clashing files hasn't been created
• MSVC could resolve them (compilation worked), but clang/clangd couldn't.
• following the headerfile-link resulted in an error message.
• renaming all other occurrences helped.

[Febbe]

I'll close this issue, since the bug (if there is any) is somewhere else. Also, it is easy to use the workaround (just don't use the same filename, even if those never appear in the same include path).