Forum Replies Created
-
Posts
-
I’ve built a cut-down toolchain and provided a corresponding test app which exercises this at the following location:
Do note that the project settings points at the custom “$(ToolchainDir)\toolchain.cmake” file, in case you want to use it with your own projects for testing.
>> 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.
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
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
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.Great, thanks for that.
I’ll test this in the next few days when I get the chance. Much appreciated!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.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.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.
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.
