Request for clarification arduino IDE toolchain selection

[jantje]

From the "package index specification":

arduino-cli/docs/package_index_json-specification.md

Lines 166 to 167 in 6ac5f7a

	missing.<br> Note that this information is not used to select the toolchain during compilation. If you want this
	specific version to be used, you should use the notation `{runtime.tools.TOOLNAME-VERSION.path}` in the platform.txt.

I always understood the Arduino IDE selected the tool(chain)? with the highest version number (making the assumption the latest is the one with the highest version number). However testing shows this is not Arduino IDE behaviour.

For example installing the "SparkFun Apollo3 Boards" platform (https://raw.githubusercontent.com/sparkfun/Arduino_Boards/master/IDE_Board_Manager/package_sparkfun_index.json) means installing arm-none-eabi-gcc\\8-2018-q4-major
After installing the sparkfun platform, Arduino Zero compiles with arm-none-eabi-gcc\\7-2017q4 (version 7) and not with the sparkfun tool (version 8).

Can you please specify how Arduino IDE selects the tool(chain)?

Note: IMHO the arduino framework specifies/uses platform versions and tool versions but does not specify/use toolchain versions.

[jantje]

Also the adafruit wiced in package_index.json is build with
arduino\\tools\\arm-none-eabi-gcc\\4.8.3-2014q1/bin/arm-none-eabi-g++
Though arm-none-eabi-gcc\7-2017q4 is available

[jantje]

The rule "tool with highest version number delivered for the same core/architecture" gives me a much higher build rate but still doesn't cover the whole domain.

For instance:

• Arduino IDE uses arm-none-eabi-gcc\4.8.3-2014q1 for the Arduino nrf52 primo board
• Arduino IDE uses arm-none-eabi-gcc\\7-2017q4 for the Adafruit nrf52 feather52832 board

As both boards are nfr52 boards the above rule implies they should use the same tool versions which they clearly don't.

I also see the Arduino IDE dump following for adafruit:

Using core 'nRF5' from platform in folder: C:\Users\jan\AppData\Local\Arduino15\packages\adafruit\hardware\nrf52\0.18.5

and for primo:

Using core 'arduino' from platform in folder: C:\Users\jan\AppData\Local\Arduino15\packages\arduino\hardware\nrf52\1.0.2

Seems like core is currently defined as what is in the boards.txt as [boardID].build.core

[facchinm]

So, there are many concurrent rules that apply:

1. if the tool is fully specified (e.g., {runtime.tools.avr-gcc-7.2.0-arduino1.path}), that version will be used
2. if the tool is not fully specified (e.g., {runtime.tools.avr-gcc.path}), some other things can happen:
   2a. if the core comes from the board manager, a check is performed to override the tool selection with the one "in sync" with the core (via the -prefs= modifier passed to arduino-builder)
   2b. if the core comes from git or any other untracked method, we have no clue about which version should be used, so it selects the first that get found

[jantje]

I'm talking about case 2a.

I have no clue what you mean with:

a check is performed to override the tool selection with the one "in sync" with the core (via the -prefs= modifier passed to arduino-builder)

Can you point me to the code that does this override and the code that gets the prefs?

[facchinm]

Sure, https://github.com/arduino/Arduino/blob/88fa134d07f278ea91ab39abbbd5d3e1e9e5b637/arduino-core/src/cc/arduino/Compiler.java#L277-L281 . For every runtime.tool specified by the package_json, the variable get populated and passed to arduino-builder

[jantje]

From this code I would assume the override happens in BaseNoGui.boardPreferences
Do you have a pointer to that code?

[jantje]

Some background info on what I'm doing. I'm currently running unit tests where I try to build the barebone ino file for all boards available in the unofficial hardware list.
I have excluded some boards because of problems in the past so it is not all boards, but most.

Running this test I came to the conclusion my tool selection like arduino IDE was not compliant with the arduino IDE tool selection 😮 Sloeber/arduino-eclipse-plugin#1145

Here is the reporting:

So of the 711 boards the test skipped 219 after 50 failures so 442 successes. Success means "build ok" not build like arduino IDE". Most frustrating to me is that there are quite some Arduino packaged boards in there.

So I updated the code to take tool versions instead of package versions and got these results:

636 successful 🎈 builds but again lots of arduino packaged boards.

So I switched to take the highest tool version but only consider the dependent tools of platforms that have the same architecture than the current boards architecture (where architecture is based on the foldername). Results even better (forgot to take a snapshot). But arduino primo is in the list

So I switched to take the highest tool version but only consider the dependent tools of platforms that have the same architecture than the current boards core (where core is defined as the value of the key [boardid].build.core in the boards.txt file). Results are so bad I stopped the test:

As there is a difference between what I programmed and what I think I programmed and I'm unable to figure out what the algorithm should be some help is really appreciated.

[jantje]

Based on the info provided I found this code:

https://github.com/arduino/Arduino/blob/15133a072044a822990ab77944434b3a1e134cf6/arduino-core/src/processing/app/BaseNoGui.java#L160-L193

This code selects the tools from the platform and the referenced platform preferring the tools of the referenced platform.

I tested this way in sloeber and all arduino delivered boards seem to compile fine 😃 but many 3th party boards fail 😒.

For some of the failed boards It seems like {runtime.tools.avr-gcc.path} is "assumed to exist". I mean: the boards comes without tools and does not reference a target. As GitHub search for runtime.tools only returns the 2 snippets already mentioned I fail to find where these are defined.

Some guidance would be appreciated.

[jantje]

I got Sloeber all working.

The way I think now it works (or this way is how Sloeber works):

• If the tool you want is in the core (referenced) platform take that one
• else if the tool is in the boards platform take that one
• else take an arduino maintained tool (packages/arduino/tools)

I'm not sure if only {runtime.tools.avr-gcc.path} or "all tools" are available, but for now Sloeber makes all Arduino maintained tools available.

I can update
https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.6.x-package_index.json-format-specification
and
https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5-3rd-party-Hardware-specification

Surely in the latter, the following claim:

{runtime.tools.TOOL_NAME.path} points to the latest version of the tool available.

arduino-cli/docs/platform-specification.md

Lines 769 to 770 in 6ac5f7a

	tools of Arduino AVR Boards and any other platform installed via Boards Manager. **{runtime.tools.TOOL_NAME.path}**
	points to the latest version of the tool available.

is simply not correct.

[jantje]

I wanted to update the pages but they have been moved and I do not see how I can update them now.

[per1234]

Hi @jantje. As you saw, we are now hosting the package_index.json and Arduino platform specifications in the Arduino CLI repository (since Arduino CLI is now the tool that handles these things for all the official Arduino development software). You are welcome to submit a PR for any enhancements or fixes to the documentation you would like to propose.

The documentation is hosted here:
https://github.com/arduino/arduino-cli/tree/master/docs

Some information on contributing to the docs:
https://arduino.github.io/arduino-cli/dev/CONTRIBUTING/#working-on-docs

Thanks!

[ubidefeo]

@per1234
I saw that documentation has been made regarding this task
can we close it?

[jantje]

I read this

{runtime.tools.TOOL_NAME.path} points to the latest version of the tool available.

which is IMHO not correct

[umbynos]

@per1234 what should we do about this?

[umbynos]

@jantje this issue should be solved by #1887, can you confirm it?

[jantje]

This indeed solves the problem of lack of documentation.
However IMHO with the described strategy there will be boards that no longer compile after the change.

What is the new behavior?
In the situation above where a tool is provided by multiple packages then the compiler will pick in order of priority:
    the tool provided by the board's package
    in absence of it, the tool (from a 3rd party) with the greatest version according to semver
    in case of a tie, the tool from the packager whose name comes first in alphabetic order
    The last rule is merely a way to make the tool selection fully deterministic even in the most uncommon situation.