Advanced CMake: Adding remote directories for IntelliSense

Sysprogs forums Forums VisualGDB Advanced CMake: Adding remote directories for IntelliSense

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #23337
    kurt
    Participant

    In my simple hello world project, I can’t get IntelliSense to find basic stuff like <iostream>.  It appears that the remote sysroot 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.
    #23344
    kurt
    Participant

    Correction to description above:

    • Specify a Yocto environment file I provided an empty file, ignoring toolchain errors. Use Yocto-generated environment file.
    #23365
    support
    Keymaster

    Hi,

    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.

    #23375
    kurt
    Participant

    Thanks 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.
    #23391
    support
    Keymaster

    You 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).

    #23397
    kurt
    Participant

    Thanks for the tip!

    #23406
    support
    Keymaster

    No problem. Let us know if you encounter any further issues and we will be happy to help.

Viewing 7 posts - 1 through 7 (of 7 total)
  • You must be logged in to reply to this topic.