IDE 1.6.2 platform.txt uses new undefined platform variable runtime.tools.avr-gcc.path

[jantje]

The arduino eclipse plugin does not work with arduino IDE 1.6.2 and 1.6.3
The reason is the definition of compiler.path in platform.txt
In Arduino IDE 1.6.1 in avr it is defined as
compiler.path={runtime.ide.path}/hardware/tools/avr/bin/
In Arduino IDE 1.6.2 and 1.6.3 in avr it is defined as
compiler.path={runtime.tools.avr-gcc.path}/bin/

The problem is that runtime.tools.avr-gcc.path is not defined in the platform.txt so it adds another unneeded and probably undocumented environment variable.

There is a very similar situation with sam

Can we revert back to the old way?

[ffissore]

We can't revert because the toolchain is no more installed into {runtime.ide.path}/hardware/tools/avr/bin/ (only the bundled avr one and only if you haven't upgraded the IDE yet)
This is where the IDE is creating those runtime keys https://github.com/arduino/Arduino/blob/master/arduino-core/src/processing/app/BaseNoGui.java#L761-L771

[ffissore]

With "upgrading the IDE" I meant upgrading core/tools using boards manager

[jantje]

I just upgraded AVR on my system and the {runtime.ide.path}/hardware/tools/avr/bin/ is still valid.
Anyway my main concern is not that compiler.path should be defined as {runtime.ide.path}/hardware/tools/avr/bin/

my concern is that when compiler.path is defined as {runtime.tools.avr-gcc.path}/bin/
runtime.tools.avr-gcc.path should be defined in platform.txt.
I really can't understand why code is needed to define runtime.tools.avr-gcc.path.

And just in case code is actually needed.... why is it not part of the boards manager adding it to the platform.txt when installing?

[matthijskooijman]

AFAICS, the reason that runtime.tools.avr-gcc.path is not defined in platform.txt, is that in general, a core/platform doesn't actually ship the gcc binaries and doesn't know where these will be installed. The IDE (code) downloads and installs the toolchain, and sets that variable to let the platforms know where the avr-gcc toolchain lives.

In the old situation, you had to define {runtime.ide.path} as well in code, right? In the new situation, the platform.txt makes fewer assumptions about where the toolchain is installed, which is a good thing IMHO.

[jantje]

In the old situation I defined a default for runtime.ide.path. If the platform contains one the default gets overwritten.
In the new situation I still need to define a default for runtime.ide.path (for users using arduino IDE 1.5.X to 1.6.1)
And I need to define a default for runtime.tools.avr-gcc.path (for users using arduino IDE 1.6.2 and later) to get a correct runtime.ide.path

In the new situation, the platform.txt makes fewer assumptions about where the toolchain is installed, which is a good thing IMHO.

I'm not sure whether I agree that making fewer assumptions about the toolchain location is a good thing.
But lets first assume it is
In the old situation
pre 1.5.6 compiler.path was not defined
in 1.5.6 compiler.path was defined
a89f5e6
in 1.6.2 compiler.path is defined as {runtime.tools.avr-gcc.path}/bin/
in other words platform.txt still makes more assumptions about where the compiler is than pre 1.5.6

Now what is the benefit of platform.txt of not making assumptions where the compiler is?
I always assumed that arduino bundled a compiler avr dude and IDE that works. I saw this bundling in the platform.txt and boards.txt. In the new way the folder even assumes a version for these. packages/arduino/hardware/[architecture]/[version]
I would assume that at this level you know (and want to know/enforce) which version of the compiler you want to use.

If you stick to the current solution please update https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5---3rd-party-Hardware-specification the section global predefined properties

[jantje]

Any input for me?

[razerraz]

I've just spended couple hours trying to understand why my projects won't compile anymore
This issue was particuraly vicious for me because I've AVR standalone gcc & headers installed on my system (arch linux), most of my projects was ok compiling, just some weird issues with librairies (software serial for instance) on others
Just forgot I had done an upgrade few days before, with 1.6.3 included :/

Just upset not having found this report before spending so much time, not having clear view of what was happening on that mess

[jantje]

I'd still appreciate some input here.

[matthijskooijman]

in other words platform.txt still makes more assumptions about where the compiler is than pre 1.5.6

@jantje, You're right about that. But in pre-1.5.6, the path to avr-gcc was passed to the platform.txt using an avr-specific setting of the compiler.path variable, which is inconsistent wrt sam and other platforms. In the latest code, the runtime.tools.avr-gcc.path variable is a lot better named. There is no need for any platform hard-coding (i.e. it can be defined for all platforms, so even the sam platform.txt could decide to call avr-gcc if it wanted). For sam, there is the corresponding runtime.tools.arm-none-eabi-gcc.path variable now, making things consistent again.

Now what is the benefit of platform.txt of not making assumptions where the compiler is?

The benefit is that (third-party) platform.txt files no longer have to hardcode where, inside the IDE, the toolchain lives. The toolchain can be freely moved to another location, without needing to update all platform.txt files. Since, AFAIK, the toolchains are now downloaded on-demand and installed outside of runtime.ide.path, I think the previous approach wouldn't even work.

I always assumed that arduino bundled a compiler avr dude and IDE that works. I saw this bundling in the platform.txt and boards.txt. In the new way the folder even assumes a version for these. packages/arduino/hardware/[architecture]/[version]
I would assume that at this level you know (and want to know/enforce) which version of the compiler you want to use.

Not sure what you're saying exactly here. In what way does the new way assume that stuff?

This issue was particuraly vicious for me because I've AVR standalone gcc & headers installed on my system (arch linux), most of my projects was ok compiling, just some weird issues with librairies (software serial for instance) on others

@razerraz But then you should have had local modifications to your Arduino install before? The IDE doesn't normally support a non-bundled toolchain out of the box?

[jantje]

@matthijskooijman
Thanks for the feedback.

The benefit is that (third-party) platform.txt files no longer have to hardcode where, inside the IDE, the toolchain lives.

I think this is a really good argument. It also explains the need for a sam and avr "environment variable".
However -from my point of view- it moves the problem of finding the right toolchain location from the platform (commercial) provider to the tool provider (non commercial) :-(.

Thinking about how to handle this.
I'm wondering: will 1 arduino IDE installation support 1 or more toolchain(s) for each architecture?
If more are supported (and there are already as you can install the avr toolchain with the library) how will the arduino IDE (and the toolprovider) know which version to use?

Jantje

PS A update of https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5---3rd-party-Hardware-specification is needed.

[matthijskooijman]

However -from my point of view- it moves the problem of finding the right toolchain location from the platform (commercial) provider to the tool provider (non commercial) :-(.

I don't think this commercial / non-commercial distinction always applies. Also, doing it like this simply makes sense from a technical perspective - it puts the burden of locating the toolchain at the "tool provider", which is really the only one that can know where it is installed. In your case, I think, it's a bit more complicated because you use the Arduino IDE installation to provide the toolchain, so your tool has to hardcode the path within the IDE installation, since there is not any way to query the IDE for toolchain locations. That might actually be worth considering - having a commandline option that prints toolchain locations and other automatic variables like these. I'm not sure off-hand how easy these would be to implement - IIRC the preferences/recipe variables are a bit intermixed and scattered throughout the code.

I'm wondering: will 1 arduino IDE installation support 1 or more toolchain(s) for each architecture?
If more are supported (and there are already as you can install the avr toolchain with the library) how will the arduino IDE (and the toolprovider) know which version to use?

I'm not sure if any support for this is present now (I think not). However, I think it could be implemented reasonably simply, just have the IDE track multiple versions of the toolchain, let the user select the one to use and then set the runtime.tools.avr-gcc.path to the selected one?

[damellis]

BTW, is it possible for the Eclipse plugin (or other third party tools) to
just call the command-line version of the Arduino IDE to do the
compilation?

On Tue, Apr 28, 2015 at 3:38 AM, Matthijs Kooijman <notifications@github.com

wrote:

However -from my point of view- it moves the problem of finding the right
toolchain location from the platform (commercial) provider to the tool
provider (non commercial) :-(.

I don't think this commercial / non-commercial distinction always applies.
Also, doing it like this simply makes sense from a technical perspective -
it puts the burden of locating the toolchain at the "tool provider", which
is really the only one that can know where it is installed. In your case, I
think, it's a bit more complicated because you use the Arduino IDE
installation to provide the toolchain, so your tool has to hardcode the
path within the IDE installation, since there is not any way to query the
IDE for toolchain locations. That might actually be worth considering -
having a commandline option that prints toolchain locations and other
automatic variables like these. I'm not sure off-hand how easy these would
be to implement - IIRC the preferences/recipe variables are a bit
intermixed and scattered throughout the code.

I'm wondering: will 1 arduino IDE installation support 1 or more
toolchain(s) for each architecture?
If more are supported (and there are already as you can install the avr
toolchain with the library) how will the arduino IDE (and the toolprovider)
know which version to use?

I'm not sure if any support for this is present now (I think not).
However, I think it could be implemented reasonably simply, just have the
IDE track multiple versions of the toolchain, let the user select the one
to use and then set the runtime.tools.avr-gcc.path to the selected one?

—
Reply to this email directly or view it on GitHub
#2982 (comment).

[matthijskooijman]

BTW, is it possible for the Eclipse plugin (or other third party tools) to just call the command-line version of the Arduino IDE to do the compilation?

Yup, that's possible. I was planning to suggest that in my previous comment, but it seems I forgot :-)