trioclip.blogg.se - september 2022

Deepvacuum not grabbing subdirectories code#

Build files have been written to: /Volumes/GIGABYTE/Source/CMake/test3/build

Not searching for unused variables given on the command line.

Executing command: /usr/local/bin/cmake -no-warn-unused-cli -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/clang -DCMAKE_CXX_COMPILER:FILEPATH=/usr/bin/clang++ -H/Volumes/GIGABYTE/Source/CMake/test3 -B/Volumes/GIGABYTE/Source/CMake/test3/build -G "Unix Makefiles" Successfully loaded 3 kits from /Users/benjaminwright/.local/share/CMakeTools/cmake-tools-kits.json This was the CMake tools output for the unencrypted project. Hi there, I've tried to source as many of the log files that you requested. Let's see what extension uses the wrong path. Most probably what happens is that CMake Tools sends the IntelliSense information associated to a file path and CppTools is searching for it by using a different path and that's why is not found. You should also inspect the main.cpp paths in these logs and highlight when they don't look correct. Then run the command "C/C++: Log Diagnostics" and save the "C/C++ Diagnostics" output channel for both.

Deepvacuum not grabbing subdirectories code#

Then load a c/cpp source code file (main.cpp if you only did a simple quick CMake project) and save the CppTools output channel for both. Those will contain logging information about what happens when a project is loaded and then configured. Then load each project (each having all the files closed, no editors opened) and save the CMake Tools output channel in both cases. Make sure nfigureOnOpen is not defined to false (the default is true, so if it's missing you're good). Set loggingLevel to debug for CMake Tools and CppTools. I am thinking of doing the following to know more where the root problem is. I tried following the intellisense tips and fixes found on the CMake tools help site, such as including the header files within a call to target_sources in the CMakeLists.txt file located within the subdirectory. Everything still configures and compiles without any issue however. Steps 1 to 7 repeat without any difference.Īt step 8 however, red error squiggles appear under #include "test.hpp" at the top of main.cpp, with the error message "Cannot open source file "test.hpp"" appearing when you hover over it. Intellisense should be able to locate test.hpp within the "src" subdirectory.After configuring, add #include "test.hpp" at the top of main.cpp.

In the top level CMakeLists.txt, add a call to add_subdirectory(src).

Add an empty test.hpp within the same subdirectory.

Add a CMakeLists.txt within it containing target_include_directories(target PRIVATE $.

Use "CMake: Quick Start" and allow CMake tools to configure intellisense.

Open new folder in a new window in vscode.

I also get zero configuration errors and everything still compiles perfectly just like the old project mentioned above which still has functioning intellisense. It reports red error squiggles beneath #include statements for headers contained within these subdirectories. However, I've tried multiple times now to start new CMake projects in different folders and intellisense does not to be able to open up headers in subdirectories anymore. In fact, intellisense STILL works JUST in this project folder funnily enough. With this setup intellisense worked perfectly for the headers within this subdirectory and everything compiles properly. I would call add_subdirectory() from a higher level CMakelists.txt and add a target_include_directories() within the subdirectory. Hi there, up until yesterday I was working on a CMake project that included headers from subdirectories within the project.