- This topic has 3 replies, 2 voices, and was last updated 2 years, 10 months ago by
.
-
Posts
-
We have a team of developers using the keil compiler. Everyone imported the same keil version armcc into their visualgdb installations, but we have different IDs.
Some of us have 5.36 in visualgdb (expected) and others have 5.x (unexpected).
This is causing annoying issues with source control as the 5.36 is in the project files, and people with 5.x on their machines have to modify project files so that the project points to the keil compiler on their machine, and the remember not to commit those changes (if they do, people with 5.36 will have to do the same to overwrite 5.x).
What are the steps we can take to get everyone on board with the 5.36 id?
Hi,
Installing the same (latest) version of VisualGDB on all machines should normally help. You can double-check the installed version via Help->About VisualGDB.
ok. I removed the toolchain from visualgdb, and then imported again with the version that the others had, and now I have the same 5.x id.
I’m glad there is a workaround, but it is a little concerning that different versions of VGDB will end up “seeing” (for lack of a better term) the same toolchain differently. So there is potential that someone who joins the project later, after we’ve all upgraded visualgdb again, will setup their environment and get a different ID for the toolchain. Is there a different way to manage the toolchain across the team that doesn’t have this issue?
No problem, we can clarify.
VisualGDB normally manages toolchains by keeping a list of Toolchain.xml (or CustomToolchain.xml) files that specify the toolchain type, ID, version, and other parameters. You can read more about it here.
On top of that, VisualGDB can automatically detect known toolchains from registry via the %VISUALGDB_DIR%\Rules\KnownToolchains.xml file. Specifically, VisualGDB will iterate over each ToolchainLoader element in KnownToolchains.xml, check if the registry value specified there exists and points to a valid directory, and will treat it the same way as if that directory contained a Toolchain.xml file with the contents equivalent to the ToolchainLoader instance. This mechanism is very fast, but cannot detect the exact compiler version in most cases, so it uses the hardcoded value from the ToolchainLoader element (e.g. 5.x).
The new versions of VisualGDB try to detect the version for GCC-based toolchains located via registry by looking at executable names, but it doesn’t work for Keil.
If you manually import the toolchain via the toolchain selector combo box, VisualGDB will get a chance to run the executable to query the exact version from it, and will save it to a separate Toolchain.xml file.
Hence, if you would like each machine to use the same compiler version, you can either remove the manually imported toolchain entry via VisualGDB Package Manager (so that it reverts to the generic registry-based detection), or manually point VisualGDB to the compiler executable, so that it gets a chance to query and record the exact version in a separate file.
- You must be logged in to reply to this topic.