--options-file in compile_commands.json is not parsed

[lucifer1004]

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.

[i-ky]

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 clangd/clangd#1410 (comment)).

[HighCommander4]

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.

[lucifer1004]

This option seems to be nvcc-specific.

[Funatiq]

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.