Thanks for the update, this makes sense. If you had previously selected -O0 in the regular VS Project Properties and -O2 in the stand-alone project properties, indeed the behavior would change in v5.4R3.

We had to change this because the previous logic did not provide an easy way to override the default settings provided by VisualGDB for regular (non-standalone) projects.

Generally, we would advise using the stand-alone project properties for device-specific flags (e.g. specific preprocessor macros, FPU type, etc) and the VS Project Properties pages for general C/C++ settings (optimization level, warnings, debug information). If this is not possible due to any reason, please let us know and we will help you find a workaround.

Sorry about that. For regular (non-stand-alone) projects there is no redundancy between different types of settings, as we specifically design our BSPs so that the settings specified there do not conflict with the regular VS project properties. The stand-alone projects do give you full control over all flags specified on the BSP level, however it indeed creates a possibility for conflicts.

That said, you don’t need to remember a checklist of flags – simply check VS Project Properties (not VisualGDB Project Properties) -> Configuration Properties -> C/C++ -> Command Line and you will see a detailed list of flags derived from the VS project properties (that will normally override any similar flags from the BSP).

Unfortunately, the exact names of conflicting settings are slightly different between the GCC versions (e.g. newer versions introduce more optimization levels or debug format levels), so reliably checking for all possible conflicts would be a relatively complex and error-prone task. As the scenario you described is relatively rare, we are happy to update the documentation and help you understand the exact logic behind this, however we would like to avoid introducing complex error-prone logic for handling it fully automatically, sorry.

Sorry about that. There is no need to roll back – we can add a setting to VisualGDB that will allow switching between the old and the new behavior, although the redundancy between the optimization setting in the VS properties and the manually specified flag in the stand-alone project properties may cause further disturbances in the future.

We can also create a small tool that will check the stand-alone projects for the optimization flag and would move it to the correct VS-level property, eliminating the redundancy. Depending on how your projects are structured, running a single tool followed by a command-line build could be viable. If not, we can add the setting described above.

No problem, we have added a registry setting that fully restores the old behavior for all of the projects on a specific user account.

Please try this build: VisualGDB-5.4.105.3118.msi

Then, set the HKEY_CURRENT_USER\Software\Sysprogs\VisualGDB\Settings\BSPFlagsOverridePerConfigurationFlags value in registry (REG_DWORD) to 1, or simply use the attached .reg file.

Please note that both the original change and this fix only affect the logic for generating the mcu.props file, that happens each time you change a setting on the first page of VisualGDB Project Properties and click “Apply”. Hence in order to restore the old behavior, please edit any setting on that page after updating the registry. You can verify that the mcu.props overrides the settings from the .vcxproj file by checking the “Condition” attribute, e.g.:

 <ClCompile>
<Optimization Condition="true">O3</Optimization>
</ClCompile>

The projects that were created with the old VisualGDB version and were never edited with v5.4 do not need to be updated as their mcu.props file still uses the old syntax.

Let us know if you have any further questions/suggestions and we will be happy to help.