Sysprogs forums › Forums › VisualGDB › Advanced CMake: Adding remote directories for IntelliSense
- This topic has 6 replies, 2 voices, and was last updated 5 years, 11 months ago by support.
-
AuthorPosts
-
January 11, 2019 at 05:10 #23337kurtParticipant
In my simple hello world project, I can’t get IntelliSense to find basic stuff like
<iostream>
. It appears that the remotesysroot
path wasn’t cached, so I manually added that, but I can see from “Clang IntelliSense Status” that the newly cached folder isn’t being considered, despite having restarted VS2017.The project builds and deploys fine (which means my toolchain paths should be correct), just that IntelliSense is not working. Can someone take a look why the sysroot path wasn’t captured in the first place?
Also, in the “VisualGDB Project Properties > IntelliSense Directories”, how does one add the directory? I’ve edited the remote cache to bring in the required sysroot folder, but nothing appears in this panel.
————————
VisualGDB-5.4-beta2
<span style=”text-decoration: underline;”>CMake project Settings</span>
- Specify a Yocto environment file: I provided an empty file, ignoring toolchain errors.
- Underlying build system: Ninja.
- Existing toolchain file: Pointing to a file that contains the following:
set(SDKTARGETSYSROOT "/opt/blah/sysroots/armv5e-linux-gnueabi") set(SDK_TOOLS_PATH "/opt/blah/sysroots/x86_64-linux/usr/bin/arm-linux-gnueabi") # the name of the target operating system set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR armv5e) set(CMAKE_SYSROOT ${SDKTARGETSYSROOT}) # which compilers to use for C and C++ set(CMAKE_C_COMPILER "${SDK_TOOLS_PATH}/arm-linux-gnueabi-gcc") set(CMAKE_C_FLAGS "-march=armv5e -pipe -feliminate-unused-debug-types") set(CMAKE_CXX_COMPILER "${SDK_TOOLS_PATH}/arm-linux-gnueabi-g++") set(CMAKE_CXX_FLAGS "-march=armv5e -pipe -feliminate-unused-debug-types") set(CMAKE_LINKER "${SDK_TOOLS_PATH}/arm-linux-gnueabi-ld") set(CMAKE_ASM_COMPILER "${SDK_TOOLS_PATH}/arm-linux-gnueabi-as") set(CMAKE_STRIP "${SDK_TOOLS_PATH}/arm-linux-gnueabi-strip") set(CMAKE_OBJCOPY "${SDK_TOOLS_PATH}/arm-linux-gnueabi-objcopy") # here is the target environment located set(CMAKE_FIND_ROOT_PATH "${SDKTARGETSYSROOT}") # adjust the default behaviour of the FIND_XXX() commands: # search headers and libraries in the target environment, search # programs in the host environment set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
- This topic was modified 5 years, 11 months ago by kurt.
- This topic was modified 5 years, 11 months ago by kurt.
- This topic was modified 5 years, 11 months ago by kurt.
Attachments:
You must be logged in to view attached files.January 11, 2019 at 08:31 #23344kurtParticipantCorrection to description above:
- Specify a Yocto environment file:
I provided an empty file, ignoring toolchain errors.Use Yocto-generated environment file.
January 12, 2019 at 05:10 #23365supportKeymasterHi,
No problem. We can help you get this to work.
When determining IntelliSense include paths, VisualGDB doesn’t use the GCC compiler path from the toolchain file. Instead it uses the path specified when importing the toolchain. You can configure it via VisualGDB Project Properties -> CMake project settings -> Toolchain -> (button with the wrench icon).
Then try closing the solution, deleting the ImplicitCompilerFlags.xml file from the VisualGDBCache directory and opening the VisualGDB Diagnostic Console.
Next time you open the project, VisualGDB will run the gcc from the toolchain definition with the flags reported by CMake and will detect the include directories based on that.
If this doesn’t help, please attach your ImplicitCompilerFlags.xml file, a screenshot of the toolchain definition and, the output from the diagnostics console and the CodeModel.json file from the VisualGDB\Debug directory and we will check what is going on.
January 12, 2019 at 08:38 #23375kurtParticipantThanks for the info on where IntelliSense looks at — it helps to know where to tweak things in the future. I am able to make it work now (both C++ and BSP headers are automatically detected).
Another follow-up question:
Is there a way to “trick” IntelliSense to sync/download the source (not just headers) for the BSP files?
For example, the following header is currently being sync’d automatically:
C:\Users\kurt\AppData\Local\VisualGDB\RemoteSourceCache\192.168.1.83\0006\include\bsp\hal\led.h
This header is remotely located in
/opt/blah/sysroots/armv5e-linux-gnueabi/usr/include/bsp/hal/
.The corresponding source file is remotely located in
/opt/blah/sysroots/armv5e-linux-gnueabi/usr/<strong>src</strong>/bsp/hal/
and I would like to sync these files, and F12 into the definition.
In the “IntelliSense Settings” tab, I see that there is a “List of additional source files”. Unfortunately, that’s only referencing local files and not remote files, plus it’s a per-file selection rather than a directory selection (i.e. grab all).
I can edit the yocto/toolchain file if needed.
- This reply was modified 5 years, 11 months ago by kurt.
January 12, 2019 at 19:07 #23391supportKeymasterYou can try using the Synchronized Directories page of VisualGDB Project Properties (Custom edition and higher). It allows linking a specific Linux directory to a specific Windows directory and defining the exact files that will be synchronized and the conditions for it.
However, the “go to definition” will only work for files that are a part of the project (VisualGDB cannot find a definition of a function in the .cpp file unless it knows the flags the file is built with so it can fully parse it). The easiest way to fix that would be to import the SDK sources into another VisualGDB-based project in the same solution (it doesn’t have to be fully buildable; as long as the source files are included into it and you specified the correct header directories, or let VisualGDB discover them with header discovery, it will be able to index the file contents).
January 13, 2019 at 05:07 #23397kurtParticipantThanks for the tip!
January 13, 2019 at 19:18 #23406supportKeymasterNo problem. Let us know if you encounter any further issues and we will be happy to help.
-
AuthorPosts
- You must be logged in to reply to this topic.