I’m working on a project where two different target environments use two different libraries, in this case one target needs Adafruit_ILI9341 (for wemos_d1) and the other needs ILI9341_t3 (for teensy31) and these are specified in my platformio.ini file.
Unfortunately, when I build for the demos_d1 environment, the teensy library tries to build but fails.
How can I express that specific libraries should only be built for specific environments?
It does seem strange that libraries can be installed with a broader syntax than they can be ignored. This seems to have the side effect that when you want to use two libraries that have the same name (for example, two different forks or git revisions) in two different environments, that means that they get reinstalled each time you switch.
It also means that I need to refer to a given library using two different syntaxes in the .ini file, but that’s not a huge deal.
BTW: PlatformIO 3.0 is awesome and you are my hero, Ivan. Keep up the great work!
I didn’t find a better solution. All package managers work with the ONE registry. PlatformIO allows using multiple ways how to install a library. What is more, a user can put library manually to one of Library Storages. We propose to use external extra library storages. See Library Dependency Finder (LDF) — PlatformIO v6.1 documentation
The only one thing that is common between these libraries is NAME. We support 3-rd party manifests, Arduino.properties, ARM mbed module.json and etc.
In this case, “Installation” process live on the one planet, where the Library Dependency Finder lives in another.
Thanks!!! I can’t wait when PIO Remote will be announced. It’s amazing with unique features in the market!!!
Darn. I was hoping that if I used the link to a github archive zip in lib_deps that if I then used the whole identical URL in lib_ignore it would be ignored.
So, for now I can just add the library as a lib_deps entry in all the targets that can build it, and leave it out of those that can’t.
Ahhhh. Nevermind. I delved into the mysteries of .piolibdeps and discovered that if I use the commit-id of the archive, I can use it in lib_ignore too. That will work!
The only reason I’m going to all this trouble is so those who build our project on Windows don’t get a complaint about the lack of git. For some reason they get annoyed with us.
I wanted to eliminate the dependency on git to build our project, so I changed all lib_deps to use the link to the .zip archives instead, which use the name of the branch (master) as the filename. For example:
(URLs split up to allow more “links in post” for my n00bness)
When this form is used the line lib_ignore TMC26XStepper fails to prevent this library from being compiled.
During my troubleshooting I noticed in the case of one library the subfolder created inside .piolibdeps was named master with no hash added. I discovered if I used lib_ignore master then that specific library would be ignored.
It was then I realized I could use the commit hashes instead. For example…
And then lib_ignore c1921b4 works! It prevents TMC26XStepper from being compiled.
I don’t know why lib_ignore TMC26XStepper fails to prevent the library from being compiled, but it does. We couldn’t get our Travis CI to pass whatsoever until I went through the process I just outlined.
I can only assume that when PlatformIO sees a link to a .zip file, it doesn’t take the extra notice that it’s a Github archive link and pick out the TMC26XStepper segment of the path as the ID of the library.
Was this ever a known issue? I believe I already patched up our .travis.yml file to use the latest version of PlatformIO. Also, I had the same problem within Visual Studio Code using 3.5.2b2.