I think the idea is to take cues from NPM’s and GEM’s and build in the ability to have dependencies. That would obviously make things super easy to use. Have you ever done a npm install and like 4 million libraries get installed? Easy like that 
2 Likes
Hey @psb777 , both @BDub and @wgbartley are correct, this is a temporary limitation. The desired long term solution is to have a system like NPM where a library can define it’s dependencies in the spark.json ala a depedencies section like this:
"name":"the-example",
"dependencies": {
"neopixel": "~0.2.0",
"idDHT22": "0.0.1"
}
in which the .h and .cpp files inside of “the-example” library could do things like #include 'neopixel/neopixel.h' with no trouble.
If you needed a library that depends on multiple libraries in the short term, one way to do it would be to solve it through documentation: In the README and in the firmware/examples you could require the user to include particular libraries if they expect the supplied examples to work or raise an exception if a required library cannot be included. Not ideal, but could work.
2 Likes
@jgoggins, since you cannot modify library code, it is (?) impossible to include two Spark libraries in your code and have them “see” each other since the libraries were never written that way to begin.
I have a display library that has multiple display-specific drivers. The only way, as you mentioned, to include them is via examples. I have not ported this library yet but when I do, I will report back on the experience. 
You can modify it, just update the source repo (with new revision on the spark.json) and re-validate, right?
I think @peekay123 means that you can’t update library code that you didn’t personally contribute, maybe?
That’s correct, you can’t modify the library code you attached.
Once you publish a library, when you want to update it, you can cut another release by bumping the version in the spark.json and submitting it again by clicking the "contribute library" button.
Yea, currently this is the case. Though I've started writing the spec for a library dependency mechanism. It certainly won't ship this Sprint, and the best way to get a library to work that has multiple lib dependency is to include some documentation in the example that says "For this example to work, you'll need to include library X, Y, and Z in your app."
In this case, it's probably best to fork the library in GitHub and issue a pull request to modify the library as you'd like and ask the author to re-release it in the IDE. To test it, you can make a new app and tweak the include statements a bit.
1 Like
@jgoggins, just as a note, in the Arduino world, you CAN modify libraries. It would be nice that once it’s pulled in, you can modify the code to do some tweaks if necessary.
I think forking the repo, and importing to your own personal library space is a good way to go. Then you can more easily share your work, even if it never gets accepted as a Pull Request to the main library.
Agreed, this would be nice. I think there will soon be a fairly easy way to do this. The ability to fork an individual file from a lib all within the IDE was in the original spec, but got taken out due complexity and other priorities. We also decided to take it out because we figured it'd be better to keep the forking in GitHub, where the management UI is amazing and there is really strong community understanding of open source workflows.
Right now the development priority for libraries is 1) flashable library examples from libraries (instead of copy and paste) and 2) being able to include an unpublished libraries in an app. Once #2 exists, you'll be able to fork the repo, make some tweaks, import it to the IDE, and use it in your apps. After you've dog-fooded your tweaks on your own apps, you can then issue a pull request if you want to original author, and they can then optionally re-import/re-release the library into the IDE.
4 Likes
The library docs mentions a “test” folder to contain test code - how is this used? What kind of tests can be written and how are they run?
I think it has got to do with Continuous Integration tests in future but just my wild guess
Indeed. I could imagine a world where the library import process automatically runs the user's tests and only allows a library to be published if the unit tests are passing. Also, I could see it being useful to show the potential user of a library something like "this library has 47 passing unit tests" to help them gauge library code quality.
2 Likes
Thanks for asking @mdma. The firmware/test folder in a library is for unit tests; tests that mock out ARM specific hardware and Spark specific functionality that can run on a standard GNU C++ compiler. I took a stab at specifying how a programmer or developer would utilize this capability, but did not implement a solid example yet because I was hoping someone smarter and fancier with test driven embedded development would step up and implement it, 
Here's how we want library unit tests to work.
We are eagerly awaiting someone from the community to take a crack this and issue a pull request. If you, or someone you know in this community has experience doing test driven embedded development, please encourage them to take on the task of creating a great example of embedded test driven development we can follow!
1 Like
I’ve spent some spare time this week developing the eeprom emulation layer for the external flash. I’ve developed it on standard Gnu C++, with unit test and integration tests written using Google Test and Google Mock. Since the external flash has a known behaviour, it was easily abstracted and replaced with a fake implementation that emulates flash using an in memory array.
I abstract the platform and hardware specifics with all my embedded projects that aren’t fundamentally tied to the hardware, so that you get the benefit of faster development on the desktop, and tool support etc…
Ah, I see that’s a long winded way of saying, yes I do have some test driven embedded experience. 
Although I’m not sure how I can help with library tests - other than maybe write some guidelines about how to make a library cross-compilable on the spark and the desktop. In general, to make this practical, the library has to have sufficient abstractions in place to allow the hardware and spark specific parts to be stubbed out. Unfortunately, there’s not much evidence of that in the current suite of libraries. A good guide might help there.
I like the direction you set with the test folder. Having desktop-based unit and integration tests would be a great. It would be great also if we could run those tests on the spark itself. So, I’m having a stab at getting the GTest/GMock framework to compile on the spark, since it would be really cool to have the tests running against the real hardware. It’s early days - The google libs make extensive use of stdio and posix, so I have to work around that, and then there’s the issue of program size, so time will tell if this is even possible.
2 Likes
@jgoggins, is there a suggested workaround to including unpublished libraries in an app? I am looking to test a library I have written, but I can not find a good way to do that at present. I am hesitant to publish something I haven't at least used on my own a little ;P.
I believe you can still manually add them by using the little + sign at the top. This will create two new tabs in which you can paste your .h and .ccp files.
Make sure to add the necessary includes (application.h for example).
Hmmmm. I guess that works, but the include paths will be wrong no?
Hey @MattyG, right now @Moors7 hit it right on the head:
...yes, the include paths will need to change when testing via a multi-tabbed app in the IDE.
For example, a file in a library at firmware/my-lib.h and included via #include "my-lib/my-lib.h" in a library example will go into a tab called my-lib.h in the IDE.
The include in the main app firmware (with setup() and loop()) will be #include "my-lib.h" while your testing functionality. Not ideal, but it'll work for the time being.
Cool. As long as I have someone in the know, is there anything stopping me from making a library that is only “optional” modules? I have a library that does camera triggering for a half dozen camera models over IR. In short I want both of the two following imports to bring in a shared library (shared.h lets say), but not need a “main” module ala:
#include "ir-control/sony.h" // (includes a shared.h)
-or-
#include "ir-control/canon.h"
Do I just make the prescribed files, then leave the namespace blank? Any suggestions welcome.