hi,
I have external files which will be used from multiple c++ projects. Therefore i’d like to include them without the need to copy them into the folder structure.
I was followig the C / C++ Developer Workflow on Windows. Everything runs fine when my external files (TestClass.h and .cpp) are beeing copied into the root folder of the project.
When executing tree in /home/build/ on the corss compilation container i get following structure:
[upload|MRGGQY0DMk9qZVd1dsqkLBk2pX4=]
But as soon as I inlcude files that are outside of the project folder (ClassOutside.h and .cpp) Visual Studio 2019 will create a cascaded folder structure and the torizon extension will fail at the rsync command. I noticed that the folder structure has been changed:
[upload|PVibaA8JBbSH0r1mkxy4JYAuHrY=]
error:
rsync -r ~ContainerTest/obj/x64/* ~ContainerTest/obj/ARM && rsync -r ~ContainerTest/bin/x64/* ~ContainerTest/bin/ARM exited with code 3, please see the Output Window - Build output for more details (NOTE: the build output verbosity might need to be changed in Tools Options to see more information in the Output Window).
I tried to change the setting Properties > Build Events > Remote Post-Build Event > Command line from
rsync -r $(RemoteProjectDir)/obj/x64/* $(RemoteProjectDir)/obj/ARM && rsync -r $(RemoteProjectDir)/bin/x64/* $(RemoteProjectDir)/bin/ARM
to the follwoing
rsync -r $(RemoteProjectDir)/$(ProjectName)/obj/x64/* $(RemoteProjectDir)/$(ProjectName)/obj/ARM && rsync -r $(RemoteProjectDir)/$(ProjectName)/bin/x64/* $(RemoteProjectDir)/$(ProjectName)/bin/ARM
Then the build runs without issues, and copies it to the target container (/home/torizon/ContainerTest/ContainerTest/bin etc …)
But when trying to debug, VS gets stuck (and i can only resolve it by restarting VS)
How should the settings be tweaked that it compiles, copies and debugs correctly when including external libraries?
thank you!
Greetings @dino.costa,
The changed directory structure after you include the outside files is strange. Mostly the “ContainerTest” folder inside the first “ContainerTest” folder.
Correct me if I’m wrong but if I understand correctly you added the “TestClassesOutsideProject” folder using the Visual Studio option of: Project > Add Existing Item
From what I can tell in the 2nd folder layout picture, “TestClassesOutsideProject” should be in the same folder as main.cpp normally if the files were added to the project properly.
Here’s a question have you tried the influxDB example in the developer article (C/C++ Development and Debugging on Torizon Using Visual Studio | Toradex Developer Center) you’ve been referencing? You don’t have to follow it all the way I’m just curious if you get a similar result when adding the influxDB external files in that example.
When I add the influxDB outside files to my VS project the folder structure of my project remains mostly unchanged except for the additional copies of the influxDB source files.
Best Regards,
Jeremias
hi Jeremias,
yes, i added the files within the “TestClassesOutsideProject” folder using the Visual Studio option of: Project > Add Existing Item.
following screenshot shows the path to the external files (located in TestClassesOutsideProject)
I followed the scheme as presented in the “Setting up the InfluxDB API” section, but in my case i was copying the files TestClass.h and .cpp into /include/TestClasses and then added them accordingly with “Add Existing Item”. This worked fine.
But as soon as i went a step further and tried to “Add Existing Item” without first copying the files to the folder structure (as with the ClassOutside.h and .cpp) i got this issue.
best regards,
Dino
Greetings @dino.costa,
I ran this issue by our extensions team and it turns out that this is an actual issue with how VS tries to sync the folder when adding outside items, this in turns messes with our extension. Which explains the odd folder structure you’re getting after adding outside items.
What this means is that you’ll run into a similar error anytime you try to add files/folders that our outside of the project folder. For the time being before we can create an official fix you’ll need to work around this on your side. You could either copy the files/code into the project folder itself, as you’ve done with TestClass.h and cpp this could probably be done as a pre-build local step of some kind. Another suggestion would be perhaps you could try something fancy with linking the outside files into the project folder.
Sorry for the inconvenience, but your feedback is very appreciated. As well as your directory structure example since since we are not 100% sure ourselves how VS generates this messed up folder structure.
Best Regards,
Jeremias
Hi Jeremias,
thanks. For now I’ll go with a simple workaround and wait for an official fix. Where will the fix be reported and when could that roughly be?
Best
Dino
I’ll see about informing you here on this post when this particular fix has been published. I can’t give any rough estimates yet as the extensions team still needs to nail down the root cause and give an estimate of effort.
The hope is that if the root issue isn’t too crazy then perhaps we can squeeze the fix in for the next release of the extension which is planned end of Q2 this year.
Best Regards,
Jeremias
