Inclduing other Libraries

Firmware Libraries
1

I’m currently working on a new library for the photon. My library would require the use of HW timers, and I’d like to use the SparkIntervalTimer library. Ist it common practice to just copy the current version of the library in ones own and try to keep it updated (should be possible, the uber library example tells developers to use the #ifndef/#define/#endif scheme)? Or is there some other recommended approach? I did not found any hints on dependency management in the uber example or community

Edit: Just linked the SparkIntervalTimer library with github submodules. Is this the correct procedure?

2

@ampunix,
Are compiling locally or with the web - IDE ?

3

I want to publish it in the web IDE. We’re currently testing the code also in the Web IDE.

4

@ampunix,
Then I would suggest to use the ‘include in app’ option, in that way you stay updated when the library changes, and you don’t have to worry about changes in the underlying software.
I use the same lib , and that works fine for me.

5

@marcus
I would like to publish a library on my own, I’m not writing an app. I know how to use libraries in the web IDE … but not when writing a library, requiring other libraries, which I eventually want to contribute to the particle cloud.

6

@ampunix,
I understand you, I did not mean to paternalistic, It was not completely clear to me what you meant :wink:
If you ask me how to publish your own library see the include in app button. But that you already did I presume.

In this case I would copy the code, mention the author :wink: and go for it. Incompatibility issues will be brought to your attention soon enough through raised issues by your users.

Succes!

7

thanks

8

Since the SparkIntervalTimer lib was put together by one of our best Elites @peekay123, you might want to ask his personal oppinion on this.
AFAIK he’s planned to extend this lib and give it a big overhaul, maybe you could join forces there.

And in general: It depends what kind of rework you plan on libraries.

  • Pull requests on someone elses lib might bring less “fame” but ensure to keep things together.
  • If you plan a “big” extension or give a lib a different direction fork it and publish under a new name (with giving dur credit ;-)), but try to keep pulling in new features from the original (if possible).
  • Ask if you can become a colaborator.
  • …
1 Like
9

@ScruffR I don’t want to change, extend or improve the SparkIntervalTimer library. I’m just writing something which requires HW timers …