As many of you know, I maintain a number of cores to support other AVR devices, including all post-2016 tinyAVR, and all AVR Dx-series parts. A user recently reported that they got this error on a chromebook (I have no idea how they run arduino on a chromebook, but I haven't paid any attention to chromeos since uh, about the middle of the release announcement when it became obvious that it wasn't something I would ever want and was built around fundamentally different goals and values from my own) from a board-manager-installed, latest version of megaTinyCore.
Warning: platform.txt from core 'megaTinyCore' contains deprecated compiler.path={runtime.tools.avr-gcc.path}/bin/, automatically converted to compiler.path=/usr/bin/. Consider upgrading this core.
This resulted in some other version of the toolchain, instead of the one I specified in my board manager json file being used. A version that is old, and does not support the part that the individual was using (device-specs not found when attempting to compile)
So what am I supposed to change the path to to make sure that it will use the version of the toolchain that was specified in the board manager json file, and that it won't be ignored and a path to a different version substituted for it? User tells me that they confirmed that the new toolchain package is present, which indicates that the IDE is just using the wrong version.
One of the dilemmas the Arduino tooling developers face is how to make advancements in the Arduino boards platform framework without causing disruption. A production tool release with breaking changes will cause a lot of suffering for the users so this is avoided if at all possible (and no I don't need to hear your rant about breaking changes in Arduino's tools). It is feasible to update the official platforms, but then the developers still have to consider the hundreds of 3rd party platforms. And even if they could all be updated, some people will still use outdated versions of the platform for one reason or another
So the developers sometimes perform some acrobatics in the code in order to allow the evolution of the frameworks without breaking things. This "contains deprecated ___, automatically converted to ___ " warning comes from one of those backwards compatibility preservation systems.
Arduino IDE 1.x includes a data file that is a list of obsolete property definitions along with a replacement definition:
(I linked to the file from arduino-builder version 1.5.4 because that is the version bundled with Arduino IDE 1.8.13, which the user says they are using in the issue report)
When property definition matching the "old" is found in a platform during an operation, arduino-builder replaces it with the "new" version and prints a warning in order to encourage the platform developer to update to the new system.
You can see there are some rewrite in that file related to the compiler.path property:
but these rewrites do not match the warning, which is about replacing this property definition:
compiler.path={runtime.tools.avr-gcc.path}/bin/
From Arduino's perspective, there is nothing wrong with that property definition, and there is no replacement set for it. What I suspect is that the user is using a modified version of Arduino IDE from a package repository. The people who manage these repositories are horribly offended by the idea of Arduino IDE installing its own copies of tools like avr-gcc. Their perspective is that there should only ever be a single installation of a tool like that, and that installation should be done using a package manager. So they like to tinker about in the Arduino IDE/arduino-builder codebase when creating their packages. I believe they have leveraged the existing property rewrite system to further their agenda. They make it so that the global system installation of avr-gcc from /usr/bin/ will be used by every platform automagically.
In a perfect world where everyone uses the official version of Arduino IDE, you wouldn't need to change it. You could just tell people that you only support the official Arduino IDE versions that are available from the arduino.cc "Software" page.
But if you do want to workaround this problem, you can modify the property so that it won't match against the modified "old" rewrite value. This could be something hacky like changing the property name:
(and of course also changing the name in all the references in platform.txt)
But there is another option that might be interesting:
Because the user may have multiple versions of avr-gcc installed, there is some potential ambiguity in what runtime.tools.avr-gcc.path resolves to. The Arduino tooling uses the information from the packages[*].platforms[*].toolsDependencies field of the package index to determine what to resolve this property to. But there are some situations where a package index is not present, the most common being that the user has done a manual installation of the platform to their sketchbook.
You can reduce that ambiguity by using an alternative form of the property, as documented here:
A {runtime.tools.TOOL_NAME.path} and {runtime.tools.TOOL_NAME-TOOL_VERSION.path} property is generated for the tools of Arduino AVR Boards and any other platform installed via Boards Manager.
So you can replace {runtime.tools.avr-gcc.path} with {runtime.tools.avr-gcc-7.3.0-atmel3.6.1-azduino6.path} to specify that avr-gcc@7.3.0-atmel3.6.1-azduino6 must be used. This will surely cause the property definition to no longer match the modified rewrite rules in the package repository version of Arduino IDE, and will also more carefully control the management of the tool dependencies of your platform.
The downside is that you must remember to update that line of platform.txt before you make a new platform release that specifies a different version of the tool for installation via the packages[*].platforms[*].toolsDependencies field of your package index. Otherwise the Arduino development tools will be looking for a path that doesn't exist because Boards Manager installed the tool to a different place.
Thank you for being a fountain of wisdom and knowledge regarding the hardware package definition system and related things as usual.
I will ask if they are using a version of the IDE from the package manager or one installed from arduino.cc and let them know that none of my cores are intended to support modified versions of the IDE provided in package manager repos, which are notorious for having unwise modifications that compromise functionality. .