Today we are proud to announce the release of VisualGDB 5.3 Preview 3 that introduces a new improved engine for toolchains and BSPs. The new engine completely decouples project settings from toolchain settings, letting you easily switch between different toolchain options and seamlessly open projects on machines that have different toolchain/BSP installation directories.

Toolchains

The previous VisualGDB versions stored toolchain information inside project files. E.g. if you had a Raspberry Pi toolchain installed in C:\SysGCC\Raspberry, the path would get stored inside the project file and in the related Make files (if you were using GNU Make). Opening the project on a different machine where the toolchain is installed in D:\SysGCC\Raspberry would require minor edits.  VisualGDB tried to detect the changed paths automatically and update the projects, but it did not work with all combinations of paths.

Starting from VisualGDB 5.3 Preview 3, all toolchain-specific settings are stored separately from the projects. Location, path mappings (e.g. /cygdrive/c/foo vs /c/foo or c:/foo) and other settings like extra PATH directories are now conveniently stored in the toolchain profiles under %LOCALAPPDATA%\VisualGDB\ToolchainProfiles. Instead of duplicating these settings, the projects automatically inherit them from the selected toolchain and still allow you to override any of the settings via VisualGDB Project Properties.

New per-project variables like $(ToolchainDir) and $(ToolchainMake) and environment variables like $(TOOLCHAIN_ROOT) are automatically set to point to the correct toolchain on each developer machine, so you don’t need to hardcode any paths or manually configure environment variables:

The same now works for MSBuild projects: instead of  setting the toolchain path, the projects now only need to contain the toolchain ID and version:

VisualGDB can now understand multiple versions of the same toolchain installed in different directories and let you choose a specific version for each project, so you can take it easy experimenting with a new toolchain, while using the old one for the critical projects (this is supported starting from the Custom edition). If you don’t have the same toolchain version installed on all your development machines, VisualGDB will help you choose a substitute when you open a project:

Invariant File Paths

One big limitation of the Visual C++ projects is that they normally reference all source files by their relative paths. So if your project is located in c:\Projects\Demo and the BSP package with the embedded board drivers is in c:\users\me\AppData\Local\VisualGDB, the project file will contain paths like ..\..\users\me\AppData that would cause trouble when opening the project on different machines.

So VisualGDB 5.3 Preview 3 introduces a powerful workaround to that. Instead of relying on limited Visual Studio APIs to edit the files, VisualGDB now edits the .vcxproj files directly and uses variables like $(BSP_ROOT) to encode all paths within the .vxcproj file:

This makes the project file completely independent from the locations of the toolchain, BSP, unit test frameworks or firmware packages on each development machine and avoid unnecessary noise in the source control system when the file is modified by different developers. VisualGDB automatically generates MSBuild rules for deriving paths like BSP_ROOT from the BSP ID and the toolchain ID under your %LOCALAPPDATA%, so the projects don’t need to contain any of them.

Multiple BSP Versions

Like with toolchains, we made it easy to install different versions of the same BSP side-by-side. Simply click “Allow installing multiple versions of this BSP” (Custom edition and higher) and VisualGDB will flag this BSP as a multi-version BSP:

You can then install older versions of it via the VisualGDB Package Manager without replacing the latest one:

Then simply pick the version you want when creating or editing a project and VisualGDB will associate your project with that specific version:

You can retarget projects for different BSP versions via VisualGDB Project Properties or simply disable the multiple versions for your BSP to automatically use the same version for all projects.

Backward Compatibility

The new VisualGDB build will automatically pick up existing toolchains and will also import the in-project toolchain definitions from projects created with older versions, but projects created with the v5.3 Preview 3 or later won’t build under older versions of VisualGDB (unless you re-select the toolchain from the properties dialog of the older version). Embedded projects using the new $(BSP_ROOT) syntax won’t build on the older versions of VisualGDB unless you manually create a .props file translating IDs to directories and include it from the project file:

<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
 <PropertyGroup Condition="'$(BSP_ID)' != ''">
 <BSP_ROOT Condition="'$(BSP_ID)' == 'com.sysprogs.arm.stm32'">$(LOCALAPPDATA)/VisualGDB/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.stm32</BSP_ROOT>
 </PropertyGroup>
</Project>

Try it out

You can download VisualGDB 5.3 Preview 3 here. As always, we will be excited to hear your feedback, so don’t hesitate to reach out to us via our support page  or forum.