Set relative path to toolchain in project file(s)

[curtis.hendrix]

At a high level, I would like to get the toolchain into our repository (git) for the following reasons:
1) Toolchain updates are much more “transparent” to the other developers working within the repo.  We currently have to do significant coordination and work to ensure everyone updates at the same time.  If the toolchain is checked in, then developers have much better flexibility in when their work is updated to use the new toolchain.

2) Keeping track of which version of the toolchain was used to build a specific version of firmware.  I want to be able to go to a specific commit and know exactly what toolchain was used to create the binaries.

3) Ease the work needed to revive an old project.  It’s common for embedded products to last for 5, 10, 15 years or longer, and require a few firmware changes over that time line.  I want to avoid having to try track down old toolchains.

I found the documentation here for how VisualGDB locates the toolchain. https://visualgdb.com/documentation/toolchains/  and it doesn’t look like what I’m after.

What I would like to do is to be able to set the toolchain path in one of the project files (.vcxproj, .vgdbsettings, .xml, .props, doesn’t really matter WHICH one) and have that path be relative to the project file.

Is this possible today? It doesn’t look so from the documentation, but I want to confirm that.

If not, could it get added?

 

[support]

Hi,

No problem, we will try to help.

VisualGDB used to follow this layout (stored relative paths for toolchains inside the project files), however most users would not want to check in the toolchains, and would instead have them installed manually, often in different paths.

So, we moved the logic for ensuring toolchain consistency to VisualGDB:

1. Each toolchain always has a unique ID/version combination (see toolchain.xml).
2. Each project always references a specific ID and version.
3. When you open a project, VisualGDB checks if the exact toolchain it references is installed, and uses the location when running all the tools without hardcoding it in the project file.
4. If the toolchain is not installed, but comes from us, VisualGDB suggests automatically installing it.

So, you have all the advantages of a checked in toolchain (solid versioning, each project referencing a specific version, having multiple versions installed at once) without having to overload the Git repository with rather bulky toolchains (yes, it could be a submodule).

So, to the points you mentioned:

1. You don’t actually need to coordinate toolchain updates. Assume, you wanted to switch the project from gcc 10 to gcc 12:
   1. You change the toolchain via VisualGDB GUI project files and check in the project files.
   2. Users who check out the new project version will get a prompt asking them to download the new toolchain. They could install it side-by-side with the old one (to a different directory).
   3. When they open the older version of the project, VisualGDB will automatically use the old toolchain. If they open the newer version again, VisualGDB will use the new one.
2. The toolchain version is transparently stored inside the project files. The only issue is that if you have multiple projects in the same repository, switching the toolchain would require updating all relevant project files, as opposed to just 1 git submodule reference.
3. Reviving old projects should be fine, as long as you keep the toolchain installers. If you are using our toolchains, you can download them from https://gnutoolchains.com/ and install them manually later.

So, in essence, it already works very similar to a git submodule managed by VisualGDB on a per-project basis.

We could try adding some sort of workaround for relative references, but it won’t work with the regular GUI and may cause conflicts between toolchains referenced by version and toolchains referenced by relative path. On the other hand, we could update the current toolchain system to address some of the issues you mentioned:

• We could allow adding custom toolchain repositories (e.g. SMB shares with toolchain installers), so you could backup the installers, point VisualGDB to the repository and have it install the necessary toolchains on-demand without depending on our servers.
• We could add indirect toolchain references. Where each project will reference a “toolchain version file”, that will contain the toolchain ID and version. If you would like to retarget multiple projects to a new toolchain, you would edit that single file (similar to updating a git submodule reference) and VisualGDB will recognize it and use the new toolchain for all projects using that file.

[curtis.hendrix]

I think I might have found a possible bug?  I went with the recommended route of installing GCC12 along side GCC9. I installed GCC12 on my local machine and the build server.  I updated all of the projects to use GCC12 in a work branch, pushed, but the build server is still using GCC9.  The only reason I noticed is because the build is failing because I enabled the -fanalyze flag which isn’t present in GCC9.

The projects’ .vcxproj and .xml files both have the toolchain version set to 12.3.1/13.2/R1, but the build server is still using GCC9.  It doesn’t matter if I trigger a build through the pipelines or manually try to build firmware from a Developer Command Prompt.

 

[support]

Hi,

It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey​

[curtis.hendrix]

Looks like we finally got support renewed.  I’m resuming work on this.

The build pipeline (Azure DevOps) is using the VSBuild@1 task, which uses a .proj file to build the firmware.

Azure Devops Pipeline:

- task: VSBuild@1
  inputs:
    solution: $(Build.Repository.LocalPath)Application.proj
    configuration: 'Debug'

- task: VSBuild@1
  inputs:
    solution: $(Build.Repository.LocalPath)Application.proj
    configuration: 'Release'

.proj file
<div>
<div>    <MSBuild Projects="$(MSBuildProjectDirectory)\BLE_MCU\Application\Application.vcxproj"</div>
<div>             Properties=" Configuration=$(Configuration);</div>
<div>                          Platform=VisualGDB;"</div>
<div>       ContinueOnError="ErrorAndContinue"/></div>
</div>
Everything works as expected if I build locally using the .proj file from a Developer Command Prompt for VS 2019 console.  But running the build on the build server still compiles with GCC 9, even though the projects are configured to use GCC 12.
On my local machine, GCC 9 is installed at C:\sysgcc9 and GCC 12 is installed at C:\SysGCC.
On the build server, GCC 9 is installed at C:\SysGCC and GCC 12 is installed C:\SysGCC12.

What’s really disconcerting about this is the only reason I caught this is because I added a new compiler flag as part of the GCC 12 migration that GCC 9 didn’t have, and that threw up errors.  I would have expected VisualGDB to have an explicit “Could not locate compiler X” error.

 

• This reply was modified 2 weeks ago by curtis.hendrix.

[support]

Hi,

Thanks for renewing your licenses. We will be happy to help.

For MSBuild projects, VisualGDB locates the toolchains as shown below:

1. The .vcxproj file defines the ToolchainID and ToolchainVersion variables.
2. MSBuild loads the %LOCALAPPDATA%\VisualGDB\FindToolchain.props file that matches these variables against a list of installed toolchains, and sets ToolchainDir.
3. The rest of the build rules run the compiler and other tools from ToolchainDir.

Normally, this should only find the toolchain if both ID and version match, or the version is not specified. However, modifications to project files or FindToolchain.props (e.g. hardcoding the toolchain directory) would interfere with it.

We would suggest double-checking the relevant variable definitions in the .vcxproj file and FindToolchain.props. E.g. you can try setting the version, ID, or the toolchain directory to completely broken values that would trigger a build error to see which of the statements get actually processed. It may turn out that some other property sheet or imported project file overrides some of the variables in a completely unexpected way.

[curtis.hendrix]

Okay.  The FindToolchain.props file was the missing piece. The build agent service account didn’t get the GCC12 location when the toolchain was installed on the build server.

However, I checked my user account’s %LOCALAPPDATA%\VisualGDB\FindToolchain.props file, and it also was not updated.  I downloaded and installed the toolchain (with “install for all users” checked) from here: https://gnutoolchains.com/download/

Do I need to install the toolchain in a different way to get FindToolchain.props file to automatically update?

 

[support]

Hi,

The file is automatically updated when VisualGDB is loaded inside Visual Studio. Just installing the toolchain outside VisualGDB won’t change it.

You can try running VisualGDB.exe /pkgmgr to force VisualGDB to reload the toolchain list.

If it doesn’t help, something else could be preventing VisualGDB from rebuilding the file. In this case please try renaming the file, restarting Visual Studio and creating a new MSBuild project using one of the toolchains using the wizard. If the file is not regenerated after it (or is missing some toolchains), please let us know and we will investigate it further.

[Author]

Posts