Proposal for new ArmGccPath definition
-
Since different compilers are now needed for building 3.3, 3.4 and 3.5, can I suggest that each project's build environment for each branch be changed as follows:
Branch PATH 3.3 ${ArmGccPath}:${ArmGccPath_3_3}:... 3.4 ${ArmGccPath}:${ArmGccPath_3_4}:... 3.5 ${ArmGccPath}:${ArmGccPath_3_5}:... Then we can set the following in the workspace-level build environment...
Name Value ArmGccPath_3_3 <path to 2020-q4-major ArmGccPath_3_4 <path to 10.3-2021.10 ArmGccPath_3_5 <path to 12.2> Leaving
${ArmGccPath}at the front of each project's settings keeps things backwards compatible. -
@gtj0 that's an interesting idea. The reason I don't have a problem with the present system is that I have different workspaces for each major firmware version that I might want to build. This makes better sense to me that having to switch branches of almost all the projects in the workspace when I want to switch between versions.
I'm looking to upgrade to gcc 12.2 for the next 3.4 release.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 Ah, gotcha. I hadn't thought of doing it that way probably because all of my other Eclipse based projects (I've got about 25 of them) use the Eclipse builder to just run make or ninja, etc. on existing build scripts. Since 3.3 is EOL and you're planning to move 3.4 to gcc 12.2 anyway, it'snot really an issue any more. If it becomes one for 3.6 or later versions I can easily do the separate workspace thing as you do.
Thanks!
