VisualMicro,
I fully understand the goal of a better library & build process.
The problem is that the goals you mention cannot be achieved with the current specification.
Yes it can work for simpler libraries, but not for more complex libraries or libraries
that have different maintainers for the different architectures.
Have a look at the specific examples I provided earlier.
Still not convinced, have a look at the current 1.5.4 examples.
Go down to the USB examples. They show up on an UNO and yet will create compile errors
because the UNO does not have support for USB and yet the users still sees the examples
that depend on USB support.
The .properties library specification does not have the needed capabilities
to tie libraries/examples/sketches to specific cores or more importantly specific chips within a core.
The current specification simply lumps together the capabilities of all the architectures
within a core. This is unrealistic given the vast differences between the chips that are
being supported within a core like the stock AVR "Arduino" core.
So while I admire and agree with the goals of the new .properties specification, it is a long way
from providing the desired/needed capabilities.
So far away, that I think it needs a complete reboot/restart.
As I said earlier, the current spec solves a few issues, but also creates new ones, and
leaves many current real-world 3rd party issues un-resolved.
My view is that if something like this is going to implemented and be embraced,
then it needs to take a bigger step in solving issues for everyone:
- Arduino Team developers
- users
- 3rd party library developers
- 3rd party tool developers
The problem I see with the current definition is that it was done in a vacuum without the input
of the 3rd party library and tool developers.
Because of this, we are already seeing a luke warm response towards it and even examples
where it doesn't work.
Come on Arduino Team, it is time for you guys to embrace being more open so you can actually
take advantage of the 3rd party community resources rather than having to battle them.
My view is that to come up with a system that solves many of these issues
will take the input of many people.
It can't be done by the Arduino team by itself or just by the 3rd party developers as many of the issues
for each are not seen or experienced by the others.
I also believe that many things will have to be dealt with simultaneously.
In other words, to make something like this really work, it isn't possible to be just about a library spec or a directory
structure. It also requires re-examining the actual build process itself as many of these issues actually
stem from that.
--- bill