Managing library versions over multiple projects

Apologies if this is a duplicate question, I could find similar questions in the past but nothing recent and none with a solution.

I have a number of projects of varying complexity, the simplest is only around 1000 lines, the largest the source folder is currently sitting at around 500k.

These projects use a number of different libraries some of which are common between projects.

What we'd like to do is have some way to manage which version of a library a given project uses. If you need to make a minor change to an older project you don't want to have to update every library to the latest version and all the extra re-testing and verification that then requires.

Currently we are resorting to manually moving/renaming directories depending on the project we want to built to force the system to pick up the correct version. Clearly this isn't a good solution and is far too error prone.
We could rename every library used e.g. SD becomes SD_For_A and SD.h is SD_For_A.h and then include them in the project directory but this is far from ideal.

Is there any automated way to say that project A should build using library X version 1.1, project B should build using library X version 1.2 etc...

Welcome to the forum

You could put the required library version in the same folder as the sketch to ensure that sketch uses that version

If I put the library directory in the top level of the project then it doesn't get detected.
If I put it in a src subfolder then I get compile errors due to include paths within the libraries being wrong.
I could copy the contents of the libraries src folder directly into my projects src folder but that is 1) messy and 2) risks file name conflicts between libraries.

Anything more complicated and I'm effectively back to my original option of file renaming and editing for each version.

There are ways to work around this, I suspect that's what I'm going to have to do. I just find it odd that there is no built in library version management, it's such a standard feature in other tools.
I get the idea of keeping things as simple as possible to avoid too much of a learning curve. And the automagic library detection is normally a good thing. But not being able to override it when needed is a pain from a long term code maintenance perspective.

If you have such large projects, I would expect that you're not using the Arduino IDE. Are you?

If so, my recommendation is VS Code/platformIO. PlatformIO will do the per-project library version management for you as a built in feature.

1 Like

It should do if you use quotation marks around the name of the .h file in the #include instead of angle brackets

The easiest solution i can think of is to rename the library you intend to use to it's original name + version nr. (or any other name you choose for that matter.)
As long as it is a legal name and you do not include multiple version of the same library of a different version (which have still the same class names of course) it will work like a charm

I use this method when compiling for esp8266 boards and sometimes using an older core version will not compile the newer library.

It doesn't require moving the library, just renaming and modifying the #ifdef NAME_H to prevent the double compiling of double referenced header files. With the library in it's original place, it will automatically pick the correct files to include from it's own folder.

edit: You will also need to make sure that any of the subfiles that include the main header file (like .cpp files usually) are modified to now include the new name.

My approach is to use portable installs for projects; this works only for IDE 1.x. Each portable install is fully independent (own core, own libraries, own IDE) of the others so modifications to a library in portable install A don't affect that same library in portable install B.

And a backup is easy; just zip the portable install and you have exactly everything that was used in the last build.

1 Like

Hi @Andy-A. I can suggest a couple of alternatives:

Dedicated Sketchbook

A simple way to achieve a reasonably good level of isolation of library dependencies is to use a dedicated sketchbook for each project. In addition to being a convenient location for storing your sketches, Arduino IDE installs libraries to the libraries subfolder of the sketchbook. So the sketchbook is a significant part of the sketch's "environment".

You can easily change the location of the sketchbook folder by doing the following:

  1. Select File > Preferences from the Arduino IDE menu.
  2. Set the Sketchbook location preference to the folder where you would like to store the project's dedicated sketchbook.
  3. Click the "OK" button.

With this approach, your projects will still share the same boards platform installations, including their "platform bundled" library.

Sketch Build Profiles

If you don't mind using a command line interface, you might be interested in the "build profiles" feature of the official Arduino CLI tool:

https://arduino.github.io/arduino-cli/latest/sketch-project-file/#build-profiles

This allows you to define the versions of each of the platform (AKA "core") and library dependencies of a sketch in a metadata file and ensure those versions will be used when compiling and uploading it.

The dependencies of each project is stored in a dedicated, isolated folder so you can use different versions of a given dependency in each of your projects.

This doesn't reach quite the level of build reproducibility as using a separate portable installation of Arduino IDE 1.x for each project as described by @sterretje since the version of Arduino CLI in use is still a variable in the build results. However, if you are concerned about that, it would be reasonable to simply document which version of Arduino CLI the sketch was verified with. An alternative would be to just bundle Arduino CLI with the sketch (similar to the "portable IDE" approach some have suggested here). Unlike Arduino IDE, Arduino CLI is a lightweight single executable file, so bundling it with the sketch is less impactful. But if, as stated, the goal is only to control library dependencies, the build profiles feature will be plenty sufficient.

2 Likes

Thanks. I'll probably try the alternative sketchbook locations initially since that is a simpler solution but the build profiles looks like it should do what I need if that doesn't work or I need something easier to automate.

Is there a way to autogenerate a profile? So you build with the current defaults and it adds to the profiles list one called "lastbuild" or similar that contains the options and libraries that were used?

A lot of the time you don't care too much which versions are used when you first start but you want to be able to freeze things at the point you get everything working. The tools must know which versions they are currently using so I can't imagine that getting them to output a profile with that information would be too tricky. That way any time you wanted to lock in the current configuration you simply rename the lastbuild profile to a suitable name.

Yes. Just add the --dump-profile flag to the arduino-cli compile command used to compile the sketch and it will print the profile entry to add to the sketch project file for the dependencies that were used when compiling the sketch:

https://arduino.github.io/arduino-cli/latest/commands/arduino-cli_compile/#options

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.