Paul,
What is your understanding of the "architectures=" field?
OR what does architectures=avr really mean?
I brought this up earlier but I think it got lost in the noise.
Suppose the Teensy or maniacbug1284p core is updated to be recognized by Arduino 1.5.4
What then?
I can't resolve in my head what the "architecture" field means given the current 1.5 hardware spec
vs the 1.5 library spec.
The hardware spec talks about vendor/maintainer but the 1.5 library spec
talks about "core-dependencies".
The hardware spec talks about "architectures" which live under a vendor/maintainer directory.
So if the "core-dependencies" in the .properties file refers to a vendor/maintainer core and
its sub architectures, how does a library refer to a specific architecture within a specific vendor/maintainer core?
i.e. how would a library specify that it only runs on the Teensy or maniacbug1284p core?
OR what about a core that works on any AVR architecture processor core regardless
of the vendor/maintainer:
Arduino, Teensy, manicbug1284p, Attiny.
In other words how do 3rd party cores get installed in 1.5 and
then how do libraries specify their dependency on these 3rd party cores or their
sub architectures using the .properties file?
And for products like Teensy that include Teensyduino.
Within Teensyduino, is "teensy" the vendor/Maintainer with sub architectures of avr and arm?
And if so, how does a library .properties file for an "AVR only" library
specify that it can only run on the boards that use the Teensy avr core?
As it is today, it does not appear that the .properties file can handle
3rd party cores dependencies very well.
One possible solution might be to alter the architectures field.
Perhaps something like:
architectures: vendor/architecture (optional-version)
That could potentially even allow something like:
architectures: */avr
To specify any vendor that has an "avr" architecture.
--- bill