[john]

I was able to make the repro case very simple – it was sufficient to just create an advanced CMake project and add a windows console app project to the solution, I didn’t have to do any cross-referencing. Once I added the console app, attempting to open “stm32f7xx_hal_conf.h” opens without clang intellisense (no “go” button visible.)

Project archive attached, I made no edits to either project, it’s just the LED blink template for the embedded project and the hello world template for the console app.

Attachments:

You must be logged in to view attached files.

[john]

I actually already have all header files added to the VisualGDB project – I’m using a CMake-based project and every header file has a line in one of the static library’s CMakeList.txt file, inside add_bsp_based_library(). (The project is broken into libraries to help make unit testing a little easier.) If I use Add->Existing file I get an error stating that the file is already present (as expected.) Header files appear in the solution explorer under their respective static libraries.

I thought it might be an issue with the level of indirection introduced by the static libraries, so I added a header file to the top-level add_bsp_based_executable(), and the problem still persisted.

(Also, if it’s relevant, only a single header file is also cross-included in the console application. The rest are exclusive to the embedded project and aren’t registered to the console application project as sources.)

[john]

Went ahead and renewed support. You’re spot-on that the solution includes a non-VisualGDB project; it’s a Windows C++ console app. This gets compiled and then the VisualGDB embedded project calls it via batch script as a post-build step, in order to manipulate the output binary (it does some fiddly custom modifications that there aren’t command line Windows utilities for, and I’d rather roll my own than introduce a third party dependency to the build sequence.) It’s also listed first in the build order, because it needs to be ready at the end of compiling the embedded project.

Is there a way to fix the editor issue without changing this structure? It’s very tidy to have the console app be part of the solution, as it makes sure everything is properly tracked in source control and everything gets built, preventing confusion among developers who only touch the codebase rarely.

[john]

Thanks! Everything compiles with the updated toolchain as expected.

I am experiencing intellisense issues once I move the standard up to C++20, but it sounds like those are already known and being worked on per this thread: https://sysprogs.com/w/forums/topic/c20-intellisense-support/

[If it’s relevant, intellisense seems to think that my user-defined classes are members of namespace ‘std’ and that some real members of namespace ‘std’ don’t exist.]

[john]

I took a look at those cached target files and I see the issue now, main.c is built as part of the “BSP” target. I changed the line to target_compile_definitions(BSP PRIVATE TEST_DEFINE=1) and the define is now available in main.c. This has also clarified for me that the BSP is actually only built once even when there’s two separate add_bsp_based_executable’s in the same solution, so I need to introduce any divergent behavior between the main program and the bootloader at link time, not compile time. So I can’t really get what I want with preprocessor defines anyway.

I’ll see what I can do, it’s definitely a little bit of a thorn in the side that STM32CubeMX forces you to use a main() defined in an auto-generated file if you want to use the auto-generated BSP. Suppose I can always change the entry point with a target_link_options line if it really becomes an issue.

Thanks for the help!

[Author]

Posts