I have sketch which compiled, loaded and ran fine until this afternoon but suddenly it refuses to compile. As nothing in the sketch has been changed I suspect a library and the IDE tells me that several libraries for "MFRC522_I2C.h" were found. So I am trying to use a different "MFRC522_I2C.h" library but I can't figure out how to do that. I've tried changing the name of the library used under ~/Arduino/libraries (I am using Linux) but the IDE still finds it and uses it in preference to the other. How can I make the IDE use a particular library?
Strangely, there are error messages when something "refuses to compile". If you could post the error message, someone may help you.
1 Like
Strangely, if you read my post carefully you might realise that I am asking for help on how to make the IDE use a particular library if several with the same name are available. Error messages are irrelevant to this request.
1 Like
Hi @steveinaustria. Since you have asked a general question, I can provide a general answer:
In the case where multiple installed libraries contain a header file matching an #include directive in the sketch program, the Arduino sketch build system uses a sophisticated algorithm to try to select the best of the libraries to use for the compilation. The system is documented here:
In the case where it did not select the library you intended to be used, the solution is to take some measure to influence that system to select the intended library.
Various techniques can be used to accomplish that. The specific approach will depend on the details of the situation. If you would like assistance with that, you would need to provide more information.
Thanks for the information. Sometimes however the algorithm selects the wrong library. In my example above I only suspected that the library might be the problem but I now have a concrete example. I am trying to load the Example/BLE/Scan.ino on the Arduino IDE onto my Heltec WiFiKit32 v3 board. When I try and compile the sketch it fails with the message
Mehrere Bibliotheken wurden für "BLEDevice.h" gefunden
Benutzt: /home/stevetux/Arduino/libraries/ArduinoBLE
Nicht benutzt: /home/stevetux/.arduino15/packages/Heltec-esp32/hardware/esp32/3.0.2/libraries/BLE
exit status 1Compilation error: 'init' is not a member of 'BLEDevice'
If I remove the ArduinoBLE library the sketch compiles. So my question would be: Is there a way to test whether a library version is responsible for a problem by forcing the sketch to use a particular library rather than removing the other libraries?
Do you have the Heltec boards in the additional boards part of preferences?
(https://github.com/Heltec-Aaron-Lee/WiFi_Kit_series)
Yes, I do. But I don't understand why you ask as the question I am asking here is a general one: Is there a way to test whether a library version is responsible for a problem by forcing the sketch to use a particular library rather than removing the other libraries?
Due to the complicated library search process, there is not an easy way to do this, and no way do it without re-naming libraries or changing their properties, unless you use the Arduino CLI.
There is one sure way and that is to copy the library into the same folder as the sketch and adapt the format of the #include statement in the code from say #include <Lib01.h> to #include "Lib01.h". This also protects against possibly unwanted upgrades of the libray which may introduce incompatibilities.
That's it! I don't know why I didn't think of that 
The build process is very complex as it supports so many different platforms. I have never had it 'pick' the wrong library other than when a 3rd party library was involved and that author violated the naming rules. Easily fixed. I have unravelled many 'screw ups' and all were caused by people modifying folders and files in places they should not be messing with.
I just noticed you said version, if it's just a version issue, just use the combo box to install the version you need to check. Just be aware if you do an update it will be returned to the latest. There are a couple ways to deal with that but that is another discussion.
If however you used the word version in a more generic way then the answer is YES but requires that you physically move or make a copy of the library to a place that makes it the first seen.
One way other than post #4 to learn how to do that is to do a verbose verify and then carefully analyze the verify output to see what the 'standard' order is. From that you should be able to make a specific library get processed in the order you want.
You can use the same technique I described in one of your previous topics:
Although this "vendoring" approach is definitely reasonable for standalone library dependencies, I think it is less so for "platform bundled" libraries like the "BLE" library that is the subject of this discussion.
In the case of platform bundled libraries, vendoring is probably more likely to cause incompatibilities. The reason is that the "BLE" library is a "platform bundled" library. These libraries are typically very tightly coupled to the platform code. The library developers expect that the library will always be used with the specific version of the platform it is bundled with, and with the specific dependencies of that platform version. If you vendor a platform bundled library, you violate that expectation as you can now update the platform without the library in use being updated in tandem, as would normally be the case.
2 Likes
I hadn't thought of that and I suppose also that the bundled libraries are more likely to be professionally maintained and so less likely to suffer breaking changes. I use this approach often, though, especially for libraries which are useful but not properly maintained, for example LiquidCrystal_I2C which I have hacked to reduce streams of compiler warning messages on newer ESP32 platforms.
Still on topic, hopefully, is the issue of support for simultaneously holding multiple versions of a library. For example, the JSON library (https://arduinojson.org/) is at version 7.x and is generally recommended for 32 bit MCUs, however, for small 8 bit MCUs version 6.x is recommended. Currently, that does not appear to fit with the library management model. Of course there are the workarounds but I guess it would be nice somehow to have that situation handled .
Relying on names for disambiguation is so 1980's ! Modern software packages use GUIDs of some kind to uniquely identify assets.
Edit; typo
I think you are right. Since a platform is significantly more complex than a standalone library, the minimum competence level for platform developers and maintainers is much higher than for a standalone library.
The more controlled environment (a single platform version and a fixed set of boards) under which a platform bundled library will be used gives the developers at least a fighting chance at comprehensively validating their code.
It has been, but unfortunately currently only when using the official command line tool Arduino CLI. The "build profiles" feature of Arduino CLI allows the creation of isolated and controlled dependencies environments for each project:
Arduino CLI provides the dependencies management and sketch build capabilities for Arduino IDE under the hood, so the same capability could be added to Arduino IDE without too much difficulty. The IDE developers are tracking that task here:
I'm not sure which software packages you are referring to. The dependency management systems I work with (npm, pip, Go modules, Debian packages) all use the package name as the unique identifier.
The same goes for Arduino. Each library in the Arduino Library Manager must have a unique name. So the library name is a unique identifier.
The situation is a bit less controlled for Arduino boards platforms. The 3rd party platform developers host their own package index so we don't have any way to enforce uniqueness of platform identifiers across the ecosystem. However, the user has control over which package indexes are used by the Arduino development tools (e.g., via Arduino IDE's Additional Boards Manager URLs" preference) and Boards Manager does not allow the installation of multiple platforms that have the same identifier. So at least within the user's machine there is uniqueness in platform identifiers.