You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So this is similar to #197 since I've encountered the same issue in a different setting.
I'm doing a CMake superbuild of all of KDE. For those who aren't familiar with CMake superbuilds. A CMake superbuild builds and installs a set of CMake projects in the correct order. In order for projects to find each other using find_package, all projects have to be installed (make install). A side effect of this installation is that all header files are copied to the installation directory and CMake's compilation databases will point at the copies of the header files in the installation directory instead of at the actual header file in the source tree.
Even if I modify CMake to install symlinks to the header files instead of copies of the header files to the install directory, I'd run into the same problem described in #197 because clangd doesn't resolve symlinks. Would a PR that adds an option to have clangd resolve symlinks be considered for inclusion in clangd? I realize that changing the default might break existing use cases but since I've run into this problem twice now, it would be great to have this supported in clangd as well.
If CMake installed symlinks to header files and clangd resolved symlinks, it would result in a great experience when working on multiple independent projects that have to be installed before they can be used by other projects such as often happens in CMake superbuilds. Instead of getting lost somewhere in the install directory, clangd would seamlessly navigate to the original header file in the source tree when using Goto-Definition.
The text was updated successfully, but these errors were encountered:
With the introduction of the config, we could actually allow enabling symlink resolution conditionally for a set of source files based on their path. With this, I could define a config to enable symlink resolution on all the header files in the install directory. That makes this very granular instead of all or nothing and doesn't break existing use cases.
So this is similar to #197 since I've encountered the same issue in a different setting.
I'm doing a CMake superbuild of all of KDE. For those who aren't familiar with CMake superbuilds. A CMake superbuild builds and installs a set of CMake projects in the correct order. In order for projects to find each other using
find_package
, all projects have to be installed (make install
). A side effect of this installation is that all header files are copied to the installation directory and CMake's compilation databases will point at the copies of the header files in the installation directory instead of at the actual header file in the source tree.Even if I modify CMake to install symlinks to the header files instead of copies of the header files to the install directory, I'd run into the same problem described in #197 because clangd doesn't resolve symlinks. Would a PR that adds an option to have clangd resolve symlinks be considered for inclusion in clangd? I realize that changing the default might break existing use cases but since I've run into this problem twice now, it would be great to have this supported in clangd as well.
If CMake installed symlinks to header files and clangd resolved symlinks, it would result in a great experience when working on multiple independent projects that have to be installed before they can be used by other projects such as often happens in CMake superbuilds. Instead of getting lost somewhere in the install directory, clangd would seamlessly navigate to the original header file in the source tree when using Goto-Definition.
The text was updated successfully, but these errors were encountered: