Closed elegracer closed 5 years ago
elegracer
commented
5 years ago BTW, when I use cmake to add include directories to a target like this
E.g. for Eigen3, the include dir is "/usr/local/include/eigen3", is it possible for the c++ intellisense to add this directory to do the autocomplete? Or is this a problem for the CMake extension?
bobbrow
commented
5 years ago Are eigen3 and opencv2 symlinks to the actual header folder? I can reproduce this for symlinks. We're working on some changes to autocomplete for #includes that should address this problem.
elegracer
commented
5 years ago @bobbrow Yes, that's right. They are both symlinks. Are you working on it? Thanks! Looking forward to the solution to this!
sean-mcmanus
commented
5 years ago Sure, we'll try to get #include completion working with symlinks -- VS Code has "References" icon we can use, in addition to the Folder icon support we've added.
UPDATE: Actually, VS Code (TypeScript) uses the Folder icon for symlinks to folders to we'll use that.
elegracer
commented
5 years ago Hi, in the latest insider update, I still cannot get the symlink autocomplete.. ( I supposed this issue had been solved?)
sean-mcmanus
commented
5 years ago @joueurh The fix hasn't been shipped yet. It's in a dev branch with other #include fixes, probably for 0.22.0-insiders (we have more performance work to do on it).
elegracer
commented
5 years ago 🤣 Oh I see, thank you guys for working on it! (I just cannot wait to see. huhuhuhuhuh
sean-mcmanus
commented
5 years ago @joueurh We shipped the fix for symlinked #include completion -- let us know if you're still having an issue.
elegracer
commented
5 years ago It seems that there's still a problem here.
My CMakeLists.txt has the following configuration:
# Declare dependencies
find_package(OpenCV REQUIRED)
find_package(Ceres REQUIRED)
find_package(Eigen3 REQUIRED)
find_package(yaml-cpp REQUIRED)
set(HKSLAM_INCLUDE_FILES
source/include/factor.h
source/include/global.h
source/include/hkslam.h
source/include/state.h
source/include/map/frame.h
source/include/map/keyframe.h
source/include/map/map.h
source/include/map/mappoint.h
source/include/odometry/initializer.h
source/include/odometry/tracker.h
source/include/optimizer/bundle_adjuster.h
source/include/optimizer/lie_algebra_eigen_quaternion_parameterization.h
source/include/optimizer/reprojection_error_cost.h
source/include/patch/make_unique.h
source/include/system/system.h
source/include/utility/config.h
source/include/utility/debug.h
source/include/utility/five_point.h
source/include/utility/lie_algebra.h
source/include/utility/random.h
source/include/utility/stereo.h
source/include/visualization/visualization.h
) # In this case we don't have headers, but always list them so that they appear in the IDE
set(HKSLAM_SOURCE_FILES
source/src/map/map.cc
source/src/map/keyframe.cc
source/src/map/frame.cc
source/src/map/mappoint.cc
source/src/odometry/initializer.cc
source/src/odometry/tracker.cc
source/src/optimizer/bundle_adjuster.cc
source/src/system/system.cc
source/src/utility/five_point.cc
source/src/utility/lie_algebra.cc
source/src/utility/stereo.cc
source/src/factor.cc
) # Always list the files explicitly
# Create target and set properties
add_library(hkslam
${HKSLAM_SOURCE_FILES}
${HKSLAM_INCLUDE_FILES}
)
target_include_directories(hkslam
PUBLIC
${CMAKE_CURRENT_SOURCE_DIR}/source/include
# PRIVATE
)
target_compile_features(hkslam PRIVATE cxx_std_14)
target_compile_options(hkslam PRIVATE
$<$<CXX_COMPILER_ID:GNU>:-Wall -g -ggdb -O0 -fdiagnostics-color=always -Werror=return-type>
$<$<CXX_COMPILER_ID:Clang>:-fcolor-diagnostics -g -glldb -O0 -Wreturn-type>
)
target_link_libraries(hkslam
PUBLIC
${OpenCV_LIBS}
Eigen3::Eigen
ceres
yaml-cpp
nanovis
general
fmt
spdlog
)
# Add an alias so that library can be used inside the build tree, e.g. when testing
add_library(hk::hkslam ALIAS hkslam)
And it seems that the include still has an error.
vscode user settings:
"C_Cpp.default.includePath": [
"${default}",
"/usr/include",
"/usr/local/include",
"${workspaceRoot}/include",
"${workspaceRoot}/src",
"${workspaceRoot}/source/include"
],c_cpp_properties.json
{
"configurations": [
{
"name": "Mac",
"defines": [],
"macFrameworkPath": [
"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks"
],
"compilerPath": "/usr/bin/clang",
"cStandard": "c11",
"cppStandard": "c++14",
"intelliSenseMode": "clang-x64",
"includePath": [
"${default}"
]
}
],
"version": 4
}It's very strange to me that, although #include completion for symlinks works now, cmake settings failed, e.g. spdlog in ${workspaceRoot}/external/spdlog/include.
And it should prompt Eigen inside /usr/include/eigen3, but only eigen3 inside /usr/include.
elegracer
commented
5 years ago The project can build btw.
elegracer
commented
5 years ago Only when I follow the hint of the light bulb,
{
"configurations": [
{
"name": "Mac",
"defines": [],
"macFrameworkPath": [
"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks"
],
"compilerPath": "/usr/bin/clang",
"cStandard": "c11",
"cppStandard": "c++14",
"intelliSenseMode": "clang-x64",
"includePath": [
"${default}",
"/usr/local/Cellar/eigen/3.3.7/include/eigen3",
"/usr/local/Cellar/opencv/4.0.1/include/opencv4",
"${workspaceFolder}/external/spdlog/include"
]
}
],
"version": 4
}The warning disappears, but why cmake settings not working? It worked in the insider 4...
sean-mcmanus
commented
5 years ago The only fix/change that was made after Insiders4 was avoiding signature help processing when typing #include <. It sounds like the #include completion is working (with symlinks), but you're experiencing some other configuration issues. I'm confused what you mean by "cmake settings not working". We do not actually parse CMakeLists.txt and instead rely on either a compile_commands.json to be generated from that or from another extension like CMake Tools (and they supply an includePath for us). I can move this configuration issue to a new issue page if you want, but it sounds like you have solved your issue via adding to the includePath?
elegracer
commented
5 years ago It seems that there's an issue when reading "includePath" from CMake Tools, or ...? Because when doing command+click I can navigate to the specific file.
For your last sentence, it's really a dirty solution, because the path contains version number, which would fail in the next brew upgrade..
sean-mcmanus
commented
5 years ago Yeah, if CMake Tools is working correctly, it should ignore the includePath property in c_cpp_properties.json. If you enable debug logging you can see includePaths we end up using -- you want it to not match what's in the c_cpp_properties.json since CMake Tools should be supplying it...you might want to check for CMake Tools configuration errors.
elegracer
commented
5 years ago After a loooooot of tests, it seems that when I delete .vscode directory, the usual prompt for setting the configuration provider won't show up?
Anyway, I found the solution to the problem here, after resetting the configuration provide to cmake-tools, the includePath cmake-tools provides is read by cpp-tools again.
Cheers! Maybe it would be better if cpp-tools can detect whether the configuration provider is set, then notice the user to choose one? or suggest the user to install cmake-tools and set the configuration provider to that?
sean-mcmanus
commented
5 years ago @joueurh Thanks for the feedback. We're working on changes to improve the configuration experience, so I've created an issue to track this at https://github.com/Microsoft/vscode-cpptools/issues/3088 .
schiffy91
commented
5 years ago I'm still seeing #include errors with symlinks. I'm using mainline llvm (downloaded via brew) on MacOS Mojave, and my c_cp_properties looks like:
{
"configurations": [
{
"name": "Mac",
"includePath": [
"${workspaceFolder}/**",
"/usr/local/opt/llvm/include/c++/v1"
],
"defines": [],
"compilerPath": "/usr/local/opt/llvm/bin/clang++",
"cStandard": "c11",
"cppStandard": "c++17",
"intelliSenseMode": "clang-x64"
}
],
"version": 4
}I have a very basic project that does nothing:
#include <vector>
int main () {
return 0;
}
I get the following IntelliSense error: cannot open source file "wchar.h" (dependency of "vector") and the lightbulb over #include <vector> shows this
Adding "/usr/local/Cellar/llvm/7.0.1/include/c++/v1" to the includePath of c_cp_properties fixes the problem. The catch is /usr/local/opt/llvm is a symlink to /usr/local/Cellar/llvm/7.0.1, so this shouldn't be necessary. More context: brew automatically creates unversioned symlinks at usr/local/opt so that devs can reference that path and not worry about updating build scripts whenever we run $brew upgrade. It'd be great to fix this, as I currently need to update my c_cp_properties each time I update llvm.
Happy to give more information if needed.
schiffy91
commented
5 years ago False alarm: There was a stale cache that made me think including the resolved path fixed IntelliSense. It turns out IntelliSense is fine – no bug here; instead, there's a "working-as-intended" quirk with Brew's installation of LLVM – not all the required files are self-contained. Adding "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/**" to my "includePath" variable solves the problem.
Type: LanguageService
@sean-mcmanus
Describe the bug
To Reproduce
Expected behavior
The suggestions should show up.
Screenshots
Screenshots are in the reproduce step above.
Additional context
To add up, although the autocomplete doesn't work, when I finish typing, and press "Command + Click", I can navigate to the corresponding file.
And for the green curve in the
#include "Config.h", it's because in this header file I include another header file in/usr/local/include/eigen3. InCMakeLists.txtI add this include directory to the cmake target, and I am able to navigate to that file, but the warning is just there. For more detail about this additional issue, please check 2nd floor.Intellisense output: (Debug level)