search

particle-iot / uber-library-example

The first Spark firmware library. To exemplify naming conventions and required files.
MIT License
28 stars 71 forks source link

Merge with arduinos library standard? #9

Open jacobrosenthal opened 9 years ago

jacobrosenthal commented 9 years ago

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 commented 9 years ago

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

jacobrosenthal commented 9 years ago

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 notifications@github.com 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 https://github.com/spark/uber-library-example/issues/9#issuecomment-92391692 .

joegoggins commented 9 years ago

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 commented 9 years ago

Also note the architectures flag:

On Mon, Apr 13, 2015 at 7:54 PM, Joe Goggins notifications@github.com 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.