Merge with arduinos library standard?

[jacobrosenthal]

Will Spark be wanting to merge with arduinos new library standard?
http://blog.arduino.cc/2015/04/02/arduino-ide-1-6-3-released-and-available-for-download/

[zsup]

@jacobrosenthal is there a place where their standard is documented?

[jacobrosenthal]

Been seeing it talked about in the developer group
https://groups.google.com/a/arduino.cc/forum/#!forum/developers

Looks like its documented:
https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5:-Library-specification
https://github.com/arduino/Arduino/wiki/Library-Manager-FAQ

On Mon, Apr 13, 2015 at 8:02 AM, Zach Supalla [email protected]
wrote:

@jacobrosenthal https://github.com/jacobrosenthal is there a place
where their standard is documented?

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

[joegoggins]

These specs are interesting and not all that different from the spark library spec--it would be cool to create a generalized system to distribute firmware packages that spans Spark and Arduino eco-systems.

My worry in merging would be library incompatibilities that could come from from ARM and AVR differences as well as core APIs being oriented toward different goals like connectivity vs learning. None-the-less, if we agree on the same code structuring, naming, and metadata conventions, that would be a big win, especially if these conventions could be broadly adopted by other boards/dev-kits.

[jacobrosenthal]

Also note the architectures flag:

• architectures - a comma separated list of architectures supported by
  the library. If the library doesn’t contain architecture specific code use
  “*” to match all architectures

On Mon, Apr 13, 2015 at 7:54 PM, Joe Goggins [email protected]
wrote:

My worry in merging would be library incompatibilities that could come
from from ARM and AVR differences as well as core APIs being oriented
toward different goals like connectivity vs learning. None-the-less, if we
agree on the same code structuring, naming, and metadata conventions, that
would be a big win, especially if these conventions could be broadly
adopted by other boards/dev-kits.