- This topic has 6 replies, 2 voices, and was last updated 6 years, 9 months ago by
.
-
Posts
-
Is there a way to have BSPs located in the program files directory rather than the %APPDATA% directory? Using appdata makes it impossible to use a project with two different users on the same computer which is necessary with the build server that I am using (TeamCity).
<div></div>
<div>How can I have the BSP’s install to different directory than the user’s appdata folder? I tried changing the ‘Shared Files Location’ in the project properties, but it uses relative paths. Is it possible to have that use absolute paths instead? Relative paths won’t work well if using the program files directory.</div>Hi,
Yes, you can relocate the BSP as shown in this tutorial (requires Custom edition): https://visualgdb.com/tutorials/arm/multiuser/
The issue with relocating the BSP as shown in the example is that the BSP directory is still relative to the project directory. That only makes sense if you want to include the entire BSP in source control, but the STM32 BSP alone is > 600 MB. Wouldn’t it make sense to just install all of the BSP’s and Toolchain in the VisualGDB program files directory instead? This way, every user could just open the project and compile, provided they have all the proper BSPs/toolchains installed. No environment variables would need to be configured or anything. As far as I can tell, this is how most embedded compilers operate and would allow any user on a computer (or multiple computers) to work easily with no configuration necessary.
Hi,
The Program Files directory is normally not writable (unless you launch VS as Administrator which is often not the case), so we store the downloaded files under $(LOCALAPPDATA).
We intentionally don’t pre-install ALL of the BSPs with VisualGDB as they often get updated and none of our users will probably need ALL of the BSPs for ALL supported platforms at the same time.
The STM32 BSP is indeed huge, but as the modern HDDs/SSDs are huge as well and the scenario of one computer/multiple users is relatively rare, we don’t want to change the current layout. As a possible quick workaround we could recommend creating symbolic links between the BSP directory under %LOCALAPPDATA%\VisualGDB and a shared BSP location outside the users’ appdata directories.
BTW, we are currently experimenting with storing $(BSP_ROOT) paths in the .vcxproj files instead of the relative paths to relocated BSPs and are planning to include this in the upcoming Preview 3 of v5.3. This should solve the problem you mentioned.
BTW, we are currently experimenting with storing $(BSP_ROOT) paths in the .vcxproj files instead of the relative paths to relocated BSPs and are planning to include this in the upcoming Preview 3 of v5.3. This should solve the problem you mentioned.
Regarding this statement, would that mean that I could put the BSPs in a C:\ directory and that would be an absolute path instead of relative path?
Hi,
With the new system there won’t be any path stored inside the .vxcproj file at all. Instead it will store the BSP ID and version and use the $(BSP_ROOT) syntax. When opening the project file with VisualGDB, it will automatically locate the BSP based on the ID and version and provide the $(BSP_ROOT) variable to Visual Studio so that VS can find the source files on your machine.
- You must be logged in to reply to this topic.