I am creating a project that is used on two different computers, each with a different username. When I compile the project from a different computer than the one where FastSemihosting was added, I get an error “FastSemihosting.cpp: no such file or directory” because it is looking for the users folder that was in effect when fast semihosting was added to the project. Is it possible to have VisualGDB have the files be referenced to the %APPDATA% path variable rather than a path relative to the current directory? It makes it difficult to compile the project on different users machines or with a build server.
Yes I am using the latest version, and I’m using msbuild, not makefiles. If I click on the fastsemihosting files in visual studio, it shows the paths as relative to the project, not the localappdata. Please let me know if there is a way to fix this.
This is a known issue. The automation interfaces used by Visual Studio do not support specifying paths like $(LOCALAPPDATA), so VisualGDB has to hardcode the path in the project file. Normally if you open the file on a different machine with a different user name, VisualGDB should automatically adjust the references (this may sometimes not work if the project and the $(LOCALAPPDATA) directory are located under the same drive letter).
Unfortunately on the machines I’m using, the drive letters are the same and I am running into this issue. Is it likely that this will be fixed with the next release or should I just go ahead and copy the fast semihosting files into my project?
As a part of a workaround to a different VS bug, we have experimented with editing the .vcxproj files directly instead of using the VS APIs. This mechanism seems to work, although it is not 100% stable yet. If you are interested to try it out, we could send you a preliminary build with this feature in the next 1-2 weeks.
We will include it in v5.3 if it proves stable enough. The drawback of the new mechanism is that it unloads the VS project, edits it and then reloads it back, that might cause unforeseen side effects. We will definitely include this in either the first or the second v5.3 preview and decide whether to include it in the final build based on the feedback we get.