Open lucifer1004 opened 3 months ago
Is --options-file
GCC-specific? If yes, the issue seems similar to -specs
, which is another GCC-specific argument. I think the solution could be a separate pass on compile_commands.json
(implemented as a standalone tool) to "resolve" such arguments (see https://github.com/clangd/clangd/issues/1410#issuecomment-1337103760).
Is
--options-file
GCC-specific?
In my local testing, neither clang nor gcc recognize it. Perhaps it's a different compiler that does.
So, this issue falls into the category of "compile_commands.json needs to contain commands that clang recognizes".
That said, clang does support something similar called response files. They are files that contain one command line argument per line, and are referred to using @filename
on the clang command line.
So, if the format of the option file is the same in your case, then replacing --options-file filename
with @filename
could be a workaround.
This option seems to be nvcc-specific.
I encountered the same issue for nvcc. I think CMake generates these includes_CUDA.rsp
files by default. The format of the files is a single line of command line options.
I also found out that there are flags to prevent CMake from creating those files:
set(CMAKE_CUDA_USE_RESPONSE_FILE_FOR_INCLUDES 0)
set(CMAKE_CUDA_USE_RESPONSE_FILE_FOR_LIBRARIES 0)
set(CMAKE_CUDA_USE_RESPONSE_FILE_FOR_OBJECTS 0)
That solved the issue for me, but it seems more like a workaround since response files are required on some systems.
Sometimes the generated
compile_commands.json
does not directly include-I
options, instead, the--options-file
option is used, and the-I
options are placed within a separate file.In this case,
vscode-clangd
is unable to follow the includes. But it should be possible to parse the--options-file
option and fetch the needed options there.