Using non-contributed libs in multiple projects via CLI

Firmware Libraries
1

I use C++ libraries in multiple Arduino and RedBear Duo projects without the need for copying library source code (both done using Arduino IDE). I want to use these libraries in multiple Photon projects now. For Photon, I’m using Particle CLI for compile. These are private libraries that won’t be “cloud published”, possibly not even “cloud contributed”, and the contribute step seems like it would fork the library source anyway, preventing reuse in Arduino IDE projects. Keeping the libraries local and using Particle CLI build seems practical, where only the final firmware is uploaded.

The Issue? How to single-source these local libraries across multiple Photon projects. Initial “success” in using these libraries on the Photon required copying library source code into each Photon project folder, like this:

/MyProj1/src/MyProj1.ino
/MyProj1/lib/MyLib1/src/.cpp <-- copy of original source from MyLib1
/MyProj1/lib/MyLib1/src/.h
/MyProj1/lib/MyLib2/src/.cpp <-- more copy of source from MyLib2
/MyProj1/lib/MyLib2/src/.h
/MyProj1/lib/MyLib3/src/.cpp <-- and more copies again
/MyProj1/lib/MyLib3/src/.h

/MyProj2/src/MyProj2.ino
/MyProj2/lib/MyLib1/src/.cpp <-- another copy of source from MyLib1 in another project
/MyProj2/lib/MyLib1/src/.h

Many libs, many projects, many copies. I call “particle compile photon” from within \MyProj1 and \MyProj2, and each project successfully compiles. The libraries even depend on other libraries, and it all works. But it’s no longer a single-source library: copies of library source code were needed under each project subtree.

How can I accomplish something like this:

/MyProj1/src/MyProj1.ino
/MyProj2/src/MyProj2.ino
/MyLibs/MyLib1/src/.cpp <— library source is kept in ONE PLACE
/MyLibs/MyLib1/src/.h
/MyLibs/MyLib2/src/.cpp
/MyLibs/MyLib2/src/.h
/MyLibs/MyLib3/src/.cpp
/MyLibs/MyLib3/src/.h

I began to consider explicit paths for includes, use of “no preprocessor” or “no compatibility” pragmas, looking into project.properties for explicit path definitions, etc, but I still don’t see how the compiler and linker will know what folder to pick up for these libs. I’ve been searching on this issue, probably missing something right in front of my nose…

Any pointers on reusing a common set of library source code in multiple Photon projects via Particle CLI? Is this a solved problem?

–Don

2

You should be able to use symbolic links.

1 Like
3

That tip seemed like the right idea, so I spent some time learning mklink in Windows - did I mention I’m using Windows 10? Bottom line: no luck with this yet.

I tried each option that mklink offers, one at a time. These options create symbolic/soft links and hard links. I read that some of these options are intended for files, others are for folders, and my quick read suggested /j (“folder junction”) might be the best approach on Windows. Here are all the commands I tried from within a Photon project folder:

  • mklink /j lib c:\MyLibParentFolder <- created junction folder, seemed fine
  • mklink /d lib c:\MyLibParentFolder <- created a linked folder, also seemed fine
  • mklink lib c:\MyLibParentFolder <- link shows as a file, seemed less good
  • the /h option failed to execute altogether.

In particular, the result of “/d” and “/j” allowed me to “cd” into the new link-folder (which was always named /lib within the project folder), and the “cd” showed the content of the /MyLibParentFolder as desired. So both of those results seemed promising.

However, both of these FAILED to compile with the Particle CLI compiler. The compile failure message was the same as if the /lib folder wasn’t even present. I continually reverted back to using a local copy of the libraries as “/lib”, just to be sure the compile worked with a local copy of the libraries and nothing else was going wrong. The folder with a true local copy of the libraries always succeeded.

Any tips on where I may have gone wrong? Or maybe this is a bug / enhancement to the Photon compile process?

4

If you want to use libraries in a current v2.0 project you should place these libraries in the dedicated lib folder.

C:.
├───lib
│   └───library1
│       └───src
│   └───library2
│       └───src
└───src

Only actual project filse should live under ./src

5

To close on your earlier guidance, do you think symbolic/hard links should be supported by Particle CLI? It would solve this problem, but it appears to be unsupported. Anything next on that? Or do you think this need is best served by Library 2.0 and keep the focus on that?

Regarding Library 2.0 Beta, I read through those pages, including doc and current state. It wasn’t apparent to me that Lib2.0 enabled a folder structure as you depict. Can you point me to some links/docs that spell that out a bit? I have some obvious questions from the example you cite of course, such as whether “C:\lib” just an example of what could be specified with Libraries 2.0, and if so, how to specify that ? I’ll pursue the Beta if it is intended to handle the case we’re discussing.

6

Actually it was C:. which stands for the current directory on C:

In particlular this was the output of

C:\temp\test\demo\tree

and links were supported last time I tried :wink: