I'm using Visual Studio Code to manage a C project that contains a number of libraries and fully-linked executables. When the executables need to depend on headers from a library, rather that point at the library's source files directly, they point at a build directory containing the headers. That is, for a source layout like:
- project/lib/src/lib.h
- project/exe/src/exe.c
Rather than the build for project/exe including -I project/lib/src, it does -I project/lib/build, which will have a copy of lib.h in it from the last time the library was built. This is done for miscellaneous reasons that don't matter here, and mostly works fine, except when I use vscode's "Go to Definition" feature (F12, Ctrl+Click, etc.).
Because vscode is using the compiler's include path to know where to find headers, if I go to the definition of anything in lib.h, vscode will open project/lib/build/lib.h instead of project/lib/src/lib.h. Is there a way, either built-in or via a plugin, to hook vscode's belief that it should open project/lib/build/lib.h and change it to project/lib/src/lib.h? I'm even willing to write a plugin, but I couldn't find a way to either modify the language server's result to change the path, or intercept vscode attempting to open a particular path and change it on-demand.
