nrobinson2000 on get
add deprecation notice to readm… (compare)
nrobinson2000 on get
add deprecation notice to insta… (compare)
nrobinson2000 on master
Update README.md (compare)
Does installing these packages help?:
sudo apt-get install gcc-multilib libncurses5:i386
@emdash Long before Particle created the updated library structure that is used by Workbench and particle-cli, I had developed my own system for managing a centralized directory of installed libraries that would get symbolically linked into each project directory. When Particle announced the new structure for libraries I decided to add compatibility for the structure to po-util by integrating workbench's makefile. My old (legacy) system still exists within po-util.
I agree that it would be better for Workbench/particle-cli to utilize a local centralized directory of libraries instead of requiring users to make a copy of a library in each project.
I have been dreaming of creating new utility similar to po-util that would make use of more of the new tools that Particle is developing, but I'm not sure if it would be necessary if Particle added the features to the tools themselves.
@emdash Could you describe your situation a little bit more? I just made a repository to test using a library as a git submodule and it works pretty well. https://github.com/nrobinson2000/submodule-test
I'm getting the same issue. It's probably something to do with the symbolic links. Personally I've switched to using the official Particle structure for all of my projects because of its interoperability with Workbench and particle-cli. I would like to make a system that uses git submodules in the future.
If I use SparkIntervalTimer in an officially structured project it works fine:
particle project create --name interval-test . cd interval-test particle library copy SparkIntervalTimer mv src/interval-test.ino src/interval-test.cpp vim src/interval-test.cpp # Load in demo po photon build-beta
To anyone who still uses this gitter, I am proud to release
neopo, a replacement for