Too many levels of include directories in VS project

Sysprogs forums Forums VisualGDB Too many levels of include directories in VS project

Tagged: ,

This topic contains 2 replies, has 2 voices, and was last updated by  tankslapper 1 year ago.

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
  • #30549


    We’re using CubeMX to generate a .gpdsc file, which VisualGDB 5.5r4  parses to create a Visual Studio project. When the project is compiled, it fails because it finds LwIP #defines that are duplicates of the C++ standard, e.g. ENOMEM. The warning happens because the low-level LwIP header folders are included in the Include Directories list as a result of parsing the .gpdsc file. When the folders are manually removed from the Include Directories list the project compiles OK. This is not ideal: it would be nice if no manual intervention were required.

    A proposed solution: the VisualGDB project properties page could contain new list of excluded include directories.

    Alternatively, the directories could be excluded from the parse after a line of the following format is seen:
    <file category=”header” condition=”” name=”Middlewares\Third_Party\LwIP\src\include\*“/>

    When a header line is seen, along with a “*” wildcard at the end, omit all the following header lines with the same parent path.

    A partial, example .gpdsc file is attached. Any feedback would be appreciated. Thanks.




    The STM32CubeMX tool indeed often generates somewhat broken code. Unfortunately, the exact behavior varies from version to version, and some configurations of settings indeed require manual adjustments.

    Adding a brand new setting to cancel out automatically imported include directories could create unnecessary complexity (e.g. forgetting about that setting would make it look that the regular Include Directories setting got totally broken). Instead, we would advise simply patching the STM32CubeMX importing plugin. It is fully open-source, so you can simply modify it to exclude certain include directories that match a certain pattern (e.g. before the ApplyFreeRTOSFixes() method is called), and replace the version shipped with VisualGDB by the customized version.

    If the behavior isn’t fixed on the ST side in a couple of months, please feel free to post an update here and we will recheck it and include a permanent fix for it on our side.



    Hi support, many thanks for your quick help! If I find a solution I’ll post it here.

Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.