Explaining project format changes in VisualGDB 5.3

The latest VisualGDB 5.3 release introduces a few improvements in the project format that avoid hardcoding of the paths and settings in the project files and make toolchain management on different machines easier. However some of those changes are not backward compatible with VisualGDB 5.2 and earlier, making it harder to update to v5.3 if some of the developers in your organization are still using v5.2. In this post I will show you the project file format differences between VisualGDB 5.3 and 5.2 and will provide examples on making v5.3 projects compatible with the older VisualGDB versions.

Non-Embedded Projects

The only change for non-embedded projects is the transition from storing the detailed toolchain information in .vgdbsettings files to only storing the toolchain ID and version and loading the details from a directory under %LOCALAPPDATA%. Below is the comparison of a .vgdbsettings file for a simple project targeting Raspberry Pi  created with VisualGDB 5.2 and 5.3 respectively:

VisualGDB 5.2 VisualGDB 5.3

Note how the Toolchain and RemoteBuildEnvironment elements were replaced by a shorter ToolchainID element. VisualGDB 5.3 will automatically locate the toolchain corresponding to the ID and version from the project file and will automatically set the paths and environment variables from it.

The .vxcproj file will also now store the toolchain ID instead of the toolchain path:

VisualGDB 5.2 VisualGDB 5.3

For non-MSBuild projects, VisualGDB 5.3 also ensures that settings like ‘build command’ do not hardcode the toolchain path:

VisualGDB 5.2 VisualGDB 5.3

Note the new $(ToolchainMake) and $(ToolchainMakeArgs) variables that are automatically set by VisualGDB when it locates a toolchain matching the ID.

When you open a VisualGDB 5.2 project in VisualGDB 5.3, it will suggest automatically upgrading it:upgrade

The upgrade process will locate a toolchain in the local toolchain list that matches the explicit definition inside the <Toolchain> element and will insert a <ToolchainID> element referencing it. If no such toolchain is found, VisualGDB will suggest importing it:toolchain

Converted projects will have both the old <Toolchain> and the new <ToolchainID> elements.

You will be able to continue building the converted non-embedded projects with both VisualGDB 5.2 and VisualGDB 5.3. However changing the toolchain settings via v5.2 GUI will remove the <ToolchainID> element and change the <Toolchain> instead. Changing  the toolchain via v5.3 GUI will change <ToolchainID>, but will keep <Toolchain> unchanged.

If you want to build a project created with v5.3 using VisualGDB 5.2, simply add a <Toolchain> element to the .vgdbsettings file manually so that VisualGDB 5.2 can recognize it. If this is an MSBuild-based projects, also ensure you have the <Toolchain> property set in the .vcxproj file.

Embedded projects

VisualGDB improves the usability of embedded projects by using variables like $(BSP_ROOT) throughout the .vcxproj files instead of hardcoding any paths:

VisualGDB 5.2 VisualGDB 5.3

This allows opening the project on different machines with different locations of the BSP and lets VisualGDB find the files without hardcoding anything. On non-MSBuild projects VisualGDB explicitly inserts a reference to the file that defines those variables:

VisualGDB 5.3 automatically maintains the FindComponents.props file to reflect the locations of all installed toolchains and BSPs. If you want to build VisualGDB 5.3 projects on VisualGDB 5.2, simply create the FindComponents.props file manually and define the variables like BSP_ROOT conditionally:

Ensure you import if from your .vcxproj file, as pre-v5.3 VisualGDB won’t to this automatically.

Automatic updating

You can prevent VisualGDB 5.3 from automatically upgrading v5.2 projects by disabling the following setting under Tools->Options:pkg

To disable automatic toolchain definition upgrading use the setting shown below:oldtc

If you haven’t tried VisualGDB 5.3 yet, give it a try. It includes numerous improvements to building and debugging experience, supports profiling and code coverage for Linux projects and many more features. You can find the detailed changelog here: https://visualgdb.com/history/.