Sysprogs forums › Forums › VisualGDB › project transfer
Tagged: Project transfer
- This topic has 19 replies, 2 voices, and was last updated 7 years ago by
support.
-
AuthorPosts
-
April 18, 2019 at 00:02 #24705
szohar
ParticipantHi,
Thanks for the info, in order to be able to use the old project I need to be able to fix it. I did replace the $(BSP_ROOT) but still see lots of absolute path which I am not sure how to correct.
Please see the file attached.
Thanks
SharonAttachments:
You must be logged in to view attached files.April 18, 2019 at 00:06 #24707support
KeymasterLooks like you have not replaced the version of the path with the forward slashes.
Please also replace C:/Users/Avi/AppData/Local/VisualGDB/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.stm32 with $(BSP_ROOT).
April 18, 2019 at 00:18 #24708szohar
ParticipantStill getting the exact same errors, please see the file attached.
I will forward the full project directory through email to you guys. Since the other computer is oversea it is very hard for me to test it back and forth, it will be easier for you to load and compile and see that there is no errors.
Attachments:
You must be logged in to view attached files.April 18, 2019 at 22:29 #24711szohar
ParticipantHi,
I am still looking forward to an answer on this, I email the data.
Sharon
April 19, 2019 at 17:55 #24725support
KeymasterHi,
Based on what you have described, the following events take place:
- You have created a non-relocatable project based on the STM32CubeMX project sample instead of the regular relocatable project shown in the wizard.
- As the non-relocatable project hardcodes the paths to source/header files in the .vcxproj file instead of using the $(BSP_ROOT) variable, it does not open on another machine.
- Per your feedback, we have patched VisualGDB to use the correct $(BSP_ROOT) syntax when creating new projects based on STM32CubeMX and provided instructions on adjusting the project manually.
The most likely reason why the project would still not build on the other machine is because it still uses incorrect paths for some of the files. The only way to diagnose this would be to look through the build log (View->Output), locate the “cannot find source file <file>.c” message, and then search the .vcxproj file for the reference to the file mentioned in the error. Most likely this reference will still use incorrect format and updating it to use $(BSP_ROOT) should solve the problem.
If you do not want to edit the .vcxproj files manually, please consider using the same project types as shown in our tutorials until you get familiar with VisualGDB settings and constraints. We publish those tutorials specifically to help new users find the working combination of settings for their setup and we always advise using them as a starting point.
-
AuthorPosts
- You must be logged in to reply to this topic.