CMake project + Intellisense + Yocto toolchain

[tzarc]

Hi there,

So far I’ve successfully built a Windows-hosted toolchain using Yocto’s meta-mingw layer, which results in a working set of gcc/g++/ld and other standard binutils tools.

For a CMake-based VisualGDB project, I’ve added a custom CMake toolchain file which overrides the same environment variables that the Yocto toolchain overrides with its environment settings batch scripts.

After that, adapting the toolchain.xml, toolchain.props, and IntelliSense.props with appropriate paths results in a working compilation, which is great.

 

The issue however, it seems that the paths defined in IntelliSense.props are not being used by the Clang IntelliSense parser. Is this file only ever considered by MSBuild projects?

 

I have already tried enabling and disabling the “Configure IntelliSense based on CFLAGS dumped by CMake” flag, however there seems to be no effect.

When opening source files, the “path suggestion” functionality proposes adding paths such as the following:

    ../../../../../../SysGCC/custom-toolchain/sysroots/cortexa7hf-neon-poky-linux-gnueabi/usr/include

…which isn’t really appropriate for a multi-user development team, with their own preferred install paths and code paths.

 

I’ve also attempted doing things such as starting the Visual Studio IDE with all of the Yocto environment variables in-place, however this had no effect.

 

Any information pointing me at a potential fix, or anything else I can try would be wonderful.

 

Cheers,

Nick.

 

—————————-

 

Example CMake custom toolchain file entry:

 set(ENV{CC} "arm-poky-linux-gnueabi-gcc -march=armv7ve -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=${CMAKE_SYSROOT}")

Example Intellisense.props entry:

<AdditionalIncludeDirectories>%(ClCompile.AdditionalIncludeDirectories);$(ToolchainDir)/sysroots/cortexa7hf-neon-poky-linux-gnueabi/usr/include;$(ToolchainDir)/sysroots/cortexa7hf-neon-poky-linux-gnueabi/usr/include/linux;$(ToolchainDir)/sysroots/cortexa7hf-neon-poky-linux-gnueabi/usr/include/c++/7.2.0;$(ToolchainDir)/sysroots/cortexa7hf-neon-poky-linux-gnueabi/usr/include/c++/7.2.0/bits;$(ToolchainDir)/sysroots/cortexa7hf-neon-poky-linux-gnueabi/usr/include/c++/7.2.0/backward;$(ToolchainDir)/sysroots/cortexa7hf-neon-poky-linux-gnueabi/usr/lib/gcc/arm-poky-linux-gnueabi/7.2.0/include</AdditionalIncludeDirectories>

[support]

Hi,

If you are using CMake, please try the new Advanced CMake Project Subsystem. It is designed to query the compiler configuration directly from CMake and should produce much more accurate results.

[tzarc]

That’s what’s currently in-use.

I can see from the Clang IntelliSense Diagnostics Console that it’s attempting to use the compile_commands.json to retrieve CFLAGS, but there does not seem to be any update to what is being parsed.

Whenever I open a file I see something along these lines (due to autodetection):

[+0:15:38.468] Reparsing C:\Code\MyProject\MyFile.cpp due to changes in discovered include directories: [] => [c:\sysgcc\yocto-imx7-var-som\sysroots\cortexa7hf-neon-poky-linux-gnueabi\usr\include;c:\sysgcc\yocto-imx7-var-som\sysroots\cortexa7hf-neon-poky-linux-gnueabi\usr\include\c++\7.2.0\arm-poky-linux-gnueabi;c:\sysgcc\yocto-imx7-var-som\sysroots\cortexa7hf-neon-poky-linux-gnueabi\usr\include\c++\7.2.0\tr1;c:\sysgcc\yocto-imx7-var-som\sysroots\cortexa7hf-neon-poky-linux-gnueabi\usr\include\linux]

These entries are then seemingly used to pop up the suggestion to add the lines like “../../../../../../SysGCC/…..” to the project settings.

As far as I can tell, the “Advanced CMake Project Subsystem” doesn’t actually seem to be pulling in any of the CFLAGS?

I’m using CMake 3.10.2, if that helps… unsure if they’ve changed the format of the compile_commands.json that VisualGDB expects.

[tzarc]

I should point out that the compile_commands.json does indeed list every include directory required — the CMake build completes successfully, but IntelliSense is just broken.

[tzarc]

Ended up “fixing” things like this — it’s a bit “brute-force” but it works:

set(EXTRA_INCLUDE_DIRS
${TOOLCHAIN_ROOT}/sysroots/x86_64-zzzsdk-mingw32/usr/lib/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/7.2.0/include
${TOOLCHAIN_ROOT}/sysroots/x86_64-zzzsdk-mingw32/usr/lib/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/7.2.0/include-fixed
${CMAKE_SYSROOT}/usr/lib/gcc/arm-poky-linux-gnueabi/7.2.0/include
${CMAKE_SYSROOT}/usr/include/c++/7.2.0
${CMAKE_SYSROOT}/usr/include/c++/7.2.0/arm-poky-linux-gnueabi
${CMAKE_SYSROOT}/usr/include
)
foreach(INCLUDE_DIR ${EXTRA_INCLUDE_DIRS})
set(ENV{CC} “$ENV{CC} -I${INCLUDE_DIR}” CACHE STRING “” FORCE)
set(ENV{CXX} “$ENV{CXX} -I${INCLUDE_DIR}” CACHE STRING “” FORCE)
set(CMAKE_C_FLAGS “${CMAKE_C_FLAGS} -I${INCLUDE_DIR}” CACHE STRING “” FORCE)
set(CMAKE_CXX_FLAGS “${CMAKE_CXX_FLAGS} -I${INCLUDE_DIR}” CACHE STRING “” FORCE)
endforeach()

Obviously, the end result is to get the actual C++ include directories from the sysroot into compile_commands.json — seemingly the CFLAGS parser can’t work these out.
Sadly, these need to be specified in the project’s toolchain file, rather than anything in the actual toolchain directory.

[support]

Hi,

Looks like there is some sort of a configuration problem. If you are using the Advanced CMake Project Subsystem, it should not create any .props files and the project file extension should be .vgdbcmake, not .vcxproj. If you are not sure, please attach the screenshots of Solution Explorer and the first page of the wizard when you create a project and we will help you understand what is going on.

[tzarc]

There was no props file created in the project — the original post had a snippet from the props file that was added to our custom-built toolchain, such that the FindToolchain.props in VisualGDB’s local appdata could pull path data.

Further investigation showed that the CMake CFLAGS parser required all include directories to be explicitly specified such that they turn up in the resulting CMake compile_commands.json — the “automatically added” directories for libstdc++ that are added by ${CUSTOM}-g++ aren’t discovered by VisualGDB’s automatic import.
I’m wondering if it’s due to the fact that Yocto’s ${CXX} also includes arguments (see the last few lines of the original post)

No need for further investigation at the moment — we currently have a working solution — however, a mechanism for explicitly adding toolchain-specific include directories for CMake projects (relative to $(ToolchainDir)) for the IntelliSense parser to search would be great.
Defining them from within the toolchain would be preferable — we can already specify them in the project settings, but as I originally outlined this is problematic for multiple users with different install locations.

Thanks
Nick.

• This reply was modified 6 years, 2 months ago by tzarc.

[support]

Hi,

Thanks for clarifying this. We have double-checked the advanced CMake projects with yocto-based toolchains and it indeed looks like VisualGDB might ignore the environment file for some of the tests.

Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.1.2062.msi

 

[tzarc]

Great, thanks for that.
I’ll test this in the next few days when I get the chance. Much appreciated!

[tzarc]

Sadly, there’s not much change — still getting issues with IntelliSense.

Over the next couple of days I’ll try and sort out a small test solution and toolchain, hopefully you guys can replicate on your end.

Thanks again,
Nick.

[support]

Hi,

Thanks, yes, if you could send us a repro case, we should be able to fix it easily.

BTW, please try deleting the ImplicitCompilerFlags.xml file and reopening the project – unless you do that, VisualGDB will reuse the incorrect flags cached by the previous version.

[tzarc]

I recreated the project file and everything seems to be working when using the 5.4.1 build you linked above, using the Sysprogs-provided “raspberry” toolchain (i.e. no custom CMake toolchain file).
Using yocto-generated toolchains seems to be fine apart from complaining about a missing “gnu\stubs-soft.h” — it should be using “gnu\stubs-hard.h”, and seems to be guarded by __ARM_PCS_VFP.

This I can see is correctly set in the IntelliSense.props file, so I’m guessing this isn’t consulted by the new CMake-based IntelliSense parser?

 

I’ve confirmed from the output of “echo | %CXX% -dM -E – | grep “^#define” | sort” that this preprocessor directive is indeed automatically defined by the toolchain, so I’m curious how to get VisualGDB to get it to pick it up.

Interestingly enough, ImplicitCompilerFlags.xml does indeed list the correct #define, so I’m curious what’s going on!

Never mind, its existence seems to be a leftover from the raspberry toolchain execution.

 

Thanks again,

Nick.

 

 

Offending header, stubs-32.h:

#if !defined __ARM_PCS_VFP
 # include <gnu/stubs-soft.h>
 #endif
 #if defined __ARM_PCS_VFP
 # include <gnu/stubs-hard.h>
 #endif

• This reply was modified 6 years, 2 months ago by tzarc.
• This reply was modified 6 years, 2 months ago by tzarc.

[tzarc]

Is the new IntelliSense parser taking into account CMAKE_CXX_COMPILER_ARG1 from CMakeCache.txt?

I’ve put the corresponding CMakeCache.txt C++-relevant variables as a snippet below — I’m wondering if the parser is only taking into account CMAKE_CXX_COMPILER and CMAKE_CXX_FLAGS, and not invoking the compiler with the supplied argument.

Invoking the same command above, but replacing %CXX%  with just the compiler executable (i.e. no flags) results in __ARM_PCS_VFP not being defined.

 

//CXX compiler
CMAKE_CXX_COMPILER:FILEPATH=C:/DevTools/SysGCC/yocto-raspberrypi3/sysroots/x86_64-vgdbtestsdk-mingw32/usr/bin/arm-vgdbtest-linux-gnueabi/arm-vgdbtest-linux-gnueabi-g++.exe

//A wrapper around 'ar' adding the appropriate '--plugin' option
// for the GCC compiler
CMAKE_CXX_COMPILER_AR:FILEPATH=C:/DevTools/SysGCC/yocto-raspberrypi3/sysroots/x86_64-vgdbtestsdk-mingw32/usr/bin/arm-vgdbtest-linux-gnueabi/arm-vgdbtest-linux-gnueabi-gcc-ar.exe

//First argument to CXX compiler
CMAKE_CXX_COMPILER_ARG1:STRING= -march=armv7ve -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=C:/DevTools/SysGCC/yocto-raspberrypi3/sysroots/cortexa7hf-neon-vgdbtest-linux-gnueabi

//A wrapper around 'ranlib' adding the appropriate '--plugin' option
// for the GCC compiler
CMAKE_CXX_COMPILER_RANLIB:FILEPATH=C:/DevTools/SysGCC/yocto-raspberrypi3/sysroots/x86_64-vgdbtestsdk-mingw32/usr/bin/arm-vgdbtest-linux-gnueabi/arm-vgdbtest-linux-gnueabi-gcc-ranlib.exe

//Flags used by the compiler during all build types.
CMAKE_CXX_FLAGS:STRING=

//Flags used by the compiler during debug builds.
CMAKE_CXX_FLAGS_DEBUG:STRING=-g

//Flags used by the compiler during release builds for minimum
// size.
CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG

//Flags used by the compiler during release builds.
CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG

//Flags used by the compiler during release builds with debug info.
CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG

• This reply was modified 6 years, 2 months ago by tzarc.

[support]

Hi,

VisualGDB uses the flags reported by CMake via the server interface. Could you check the CodeModel.json file in your build directory (it will be fairly large, so using an online JSON formatter might help understand it). The relevant part should look like this:

"fileGroups":[
 {"compileFlags":"-g -fPIC ",<...>,"sources":["LinuxProject.cpp"]}

Do the compileFlags for your .cpp file include the flags from CMAKE_CXX_COMPILER_ARG1 ?

[tzarc]

>> Do the compileFlags for your .cpp file include the flags from CMAKE_CXX_COMPILER_ARG1 ?

Not at all — just CMAKE_CXX_FLAGS_DEBUG and the project-specific flags.

[Author]

Posts