Force compiler to use only chosen library

Projects Programming
1

I have been trying to force the compiler to use only the library i want it to use. This actually was not a big issue till i started using the Teensy range of MCUs. When these boards are installed the create a full set of their own libraries in " C:\ProgramFiles(x86)\Arduino\avr..."

Having tried many ways i now simply comment out the unwanted library and even then the compiler warns about multiple libraries found and using so and so.. like below :

Multiple libraries were found for "SPI.h"
 Used: C:\Users\RRNathan\Documents\Arduino\libraries\SPI
 Not used: C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\SPI
Multiple libraries were found for "Wire.h"
 Used: C:\Users\RRNathan\Documents\Arduino\libraries\Wire
 Not used: C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\Wire
Multiple libraries were found for "SD.h"
 Used: C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\SD
 Not used: C:\Program Files (x86)\Arduino\libraries\SD

Is there a proper method to handle this situation ? ( Would deleting all other libraries expect those in the Sketchbook Location be one of the ways ??)

2

Mogaraghu:
Having tried many ways i now simply comment out the unwanted library

It's not clear what you mean by that. Please supply more details.

Mogaraghu:
the compiler warns about multiple libraries found and using so and so..

That's just some helpful information. As long as it's picking the right library what's the problem?

3

pert:
It's not clear what you mean by that. Please supply more details.

To clarify ... When I develop code for a UNO I want the compiler to use this library :
C:\Users\RRNathan\Documents\Arduino\libraries\Wire

When I develop code for Teensy3.5 I want to use this library ( The native Arduino Wire library throws a fault when used with Teensy )
C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\Wire

So now what I do is to comment out the Wire library in my Sketch Folder and thereby force the compiler to use the one in teensy folder.

But I thought there must be a way to instruct the complier to use a specific library from the many on the disk

4

Give the libraries different names or include them explicitly with a full path name

...R

5

Mogaraghu:
So now what I do is to comment out the Wire library in my Sketch Folder and thereby force the compiler to use the one in teensy folder.

I don't understand why you have a Wire library in your Sketch folder; can you explain ?

6

you can try to use the preprocessor to force selection of the right library based on the device type:

something like this (untested)

#if defined(CORE_TEENSY)
  #include "myLib.h"
#else
  #include <Wire.h>
#endif
7

stowite:
I don't understand why you have a Wire library in your Sketch folder; can you explain ?

That can be useful if you want to ensure that a program always uses the same version of a library even though the "shared" version of the library gets updated.

It also means that if you copy the code from one computer to another the library goes with it.

However if I have a library in my Sketch folder I include it with #include "myLib.h" and I was not aware that the IDE would search anywhere else for it. I normally use IDE 1.6.3 and maybe the newer versions are "improved"

...R

8

Mogaraghu:
To clarify ... When I develop code for a UNO I want the compiler to use this library :
C:\Users\RRNathan\Documents\Arduino\libraries\Wire

When I develop code for Teensy3.5 I want to use this library ( The native Arduino Wire library throws a fault when used with Teensy )
C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\Wire

That's a tough one. The problem really comes down to you having the Wire library in your sketchbook folder. Is that actually necessary? If it wasn't there then the Uno would automatically use the library at C:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\Wire and the Teensy would use C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\Wire.

The worst part is that the Teensy 3.5 isn't actually an AVR but for some reason Teensyduino puts non-AVR boards in the avr architecture folder. If it wasn't so then (relatively recent versions of) the Arduino IDE would indeed behave as you want it to since it uses the architecture value in library.properties as one of the factors for determining include priority.

Mogaraghu:
So now what I do is to comment out the Wire library in my Sketch Folder and thereby force the compiler to use the one in teensy folder.

That still makes as little sense as the first time you said it. How do you comment out a library? Even if you commented all the code it would still get included.

Robin2:
However if I have a library in my Sketch folder I include it with #include "myLib.h" and I was not aware that the IDE would search anywhere else for it. I normally use IDE 1.6.3 and maybe the newer versions are "improved"

The "" syntax causes the local folder of the file that contains the #include statement to be searched first, then all the other standard library folders. I don't remember a time it was ever not that way. I think I would have noticed because a lot of code uses the incorrect #include syntax, but it usually ends up working anyway.

9

pert:
The "" syntax causes the local folder of the file that contains the #include statement to be searched first, then all the other standard library folders.

I apologize for my ignorance.

I presume if you use a full path name to the library it does not go looking in unwanted corners ?

...R

10

Robin2:
I presume if you use a full path name to the library it does not go looking in unwanted corners ?

I don't think it's really relevant because an absolute path is what it is, it's not relative to a specific search location so it would be pointless to search for it "locally" as well as in the include path. It definitely doesn't pull just the filename out of the path and search for that in the library folders. For example, if I do this:

#include "c:\Wire.h"

Where Wire.h doesn't exist at c:\ but Wire.h is present in one of my library folders, I still get: "fatal error: c:\Wire.h: No such file or directory". So either way it's not something to worry about other than maybe a little bit longer delay before the compilation fails as it unnecessarily does multiple identical searches for the file.

Here's a pretty good, if necessarily vague description of how it's supposed to work:

http://en.cppreference.com/w/cpp/preprocessor/include:

#include (1)
#include "filename" (2)
...

  • Searches for the file in implementation-defined manner. The intent of this syntax is to search for the files under control of the implementation. Typical implementations search only standard include directories. The standard C++ library and the standard C library are implicitly included in these standard include directories. The standard include directories usually can be controlled by the user through compiler options.
  • Searches for the file in implementation-defined manner. The intent of this syntax is to search for the files that are not controlled by the implementation. Typical implementations first search the directory where the current file resides and, only if the file is not found, search the standard include directories as with (1).
11

pert:
Where Wire.h doesn't exist at c:\ but Wire.h is present in one of my library folders, I still get: "fatal error: c:\Wire.h: No such file or directory".

But that means that using a full path name would solve the OP's problem.

...R

12

That does seem like it works. I never use full path includes and the one time I recommended someone to use one it ended up not working but I just tested the Wire include.

So if you want the same sketch to work with either board you could do this:

#if defined(CORE_TEENSY)
  #include "C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\Wire\src\Wire.h"
#else
  #include <Wire.h>  // C:\Users\RRNathan\Documents\Arduino\libraries\Wire\src\Wire.h for avr architecture or the bundled Wire library for any other architecture
#endif

That assumes Teensy defines the CORE_TEENSY macro, I don't have it installed so I can't check but if not I'm sure there's something of that sort.

13

Hmmm ... i seem to be stuck with a very disobedient compiler.

When I tried this ,

#include "C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\SPI\SPI.h"

It never listened to me and went ahead and used the one it liked.

The idea to use a different library based on the core that is being seems to be a good one but for that I should be able to get absolute paths working ...

There always will be a negative connotation to using absolute paths ... but then for a single developer working on a single laptop I guess its OK . Anyway I know the path is absolute and when things break know where to look.

14

So it included C:\Users\RRNathan\Documents\Arduino\libraries\SPI\src\SPI.h instead? That's strange, I can't reproduce that. Does it happen if that's the only include in your sketch?

15

Mogaraghu:
Hmmm ... i seem to be stuck with a very disobedient compiler.

When I tried this ,

#include "C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\SPI\SPI.h"

It never listened to me and went ahead and used the one it liked.

There are actually two different issues.

  • getting the header file you want included
  • getting the IDE to build and link in the correct library.

The way the IDE does its libraries is a total mess.
I've made several suggestions to fix it over the years but they all have been rebuffed mostly because I don't think the arduino core team really understood some of the issues.

The biggest issue is that the header file included is dependent on the include path.
The include path ends up with an -I option for every single header.
The issue is that when there are certain types of collisions (header file with same name in multiple places it searches for header files), it can create a situation where the compiler can end up picking a header for a different library than the IDE will build and link in.

Also, a really @#$#@ thing that the IDE does is potentially put bundled library updates into the sketchbook/libraries are. NEVER NEVER do this. It was and is a very dumb thing to do and can screw you over since it can stomp on your private version and create a situation where you break older versions of the IDE and potentially even lose the newer version of the library that comes bundled with a future IDE update.
Just don't do it unless you are doing testing and are prepared to deal with the consequences.

All that said the IDE has a search order and should pick a library that should work with the target core.
A proper library will indicate the cores that it runs on. So the IDE should ignore a library that is not for the target core even if it is a higher priority in the search order and move on to another library that is for the target core. (That assumes that an old IDE is not being used)
There are some IDEs that were just plain broken and should be avoided.

IDE versions 1.5 to 1.55 (unnecessary file name restrictions, breaks many libraries)
IDE version 1.6.6 (has function prototyping issues that can break some sketches)
IDE version 1.6.8 (has serial port issues that breaks on certain boards)

In the larger picture, I'm not quite understanding what you have done and what you trying to do.

I currently have pretty much every Arduino core, about 80 different 3rd party libraries, and every IDE since Arduino 0018 all installed on my development machine.

I also don't let the teensyduino ever install its package of libraries and I install the libraries that I want/need.

I build and test my libraries on many different cores (avr, due, atmega1284, chipkit, esp8266, teensy, teensy3) many different boards within those cores and I don't get issues like the duplicate libraries you are seeing unless I'm playing some games temporarily to move some things around to be ignored in my sketchbook/libraries area for special development purposes.

So can you step back for a moment and describe what you are really needing to do as I still don't get it.
And why you are getting all these duplicate library messages.
It almost sounds like something got installed incorrectly and you are trying to work around it.

Maybe describe what you have installed, IDE version, cores, libraries, etc... and where.

--- bill

16

@pberrybap

It was quite informative to know a little bit of what happens in the kitchen before the food is spruced up and served on the plate.

Ye my laptop is filled with libraries in zillion locations. And the only crime I did was to allow native setup programs to do what they want.

For example have a look at how many SPI.h my PC has and you will get an idea.

Ideally this is what I plan to do :

  • Pick and choose ONLY the Libraries I ever use and put them inside my sketch folder.
  • Delete all other instances or move them to a far corner out of sight from the IDE

The only catch in the above proposal would be the case where the Teensy might need a different Wire.h instead of the regular Wire.h

Spi_Locations.PNG
Spi_Locations.PNG1017×233 7.61 KB

17

A bit more background.
When the new library format was introduced at IDE 1.5 the arduino team was proposing some mechanisms to separate out the libraries for different cores.
You can read this for some information but it doesn't have some information about the early iterations:

At the time, the arduino team clearly did not understand some of complexities of supporting multiple cores and the issues for 3rd party developers, which are very different from the IDE bundled libraries and cores.
Believe it or not the first 1.5x format did not support backward compatibility with all the existing 1.x libraries.
This was essentially a repeat of the disaster of the decision that the Arduino team made when going from 1.0 RC to the official 1.0 release where 100% of all the existing 3rd party code would break.
Against some of the core Arduino team, I managed to talk the main Arduino developer into providing backward compatibility for all the existing 1.x code.

The original proposal also required that each core have a directory in the library tree for core specific code.
Several of us pushed that this was unworkable as each core needs to be able to release and maintain its own core specific library that is independent of any other version of that library. After a few IDE releases the core specific directory within a library was effectively dropped as the arduino team realized that their original proposal was unworkable and now a library can exist in multiple places and specify what cores it works on. (They saw the light as they began developing and doing maintenance for DUE)
This allows a library to be in the sketchbook/libraries area and specify which cores it works on, or be shipped with a core for a version of the library that works with that core.

This is the way you want it. That way, a 3rd party core can ship its own h/w specific version of the library that gets used when code is built for boards that use that core.
i.e. if building for UNO, the avr Wire library in the arduino avr core is use.
If building for esp8266 their Wire library is used, if building for Teensy the teensy Wire library is used and if building for teensy 3x the teensy3x library is used, etc...

So yes you can and will have certain libraries that show up in multiple places.
This is normal and is what makes things work for different cores.
The IDE will automatically detect and use the proper library for the core.
These types of libraries are the core specific libraries, for example: Wire, SPI, SoftwareSerial, EEPROM

Where things can get messy or break is when using your personal sketchbook/libraries area.
So this comment is of concern:

  • Pick and choose ONLY the Libraries I ever use and put them inside my sketch folder.

Not sure if you meant sketch folder or sketchbook/libraries folder.
I haven't followed if the IDE now allows libraries to be in the actual directory with the sketch, which it sounds like what you might doing.
If so, the key thing to remember is that in those cases, not to bundle core specific libraries as those will be in the core that the code is being built for.
i.e. don't provide libraries like Wire, SPI etc... Let the IDE use the one that comes with the core.

The sketchbook libraries (and I'm guessing sketch libraries if that is now supported) trump other library areas, so you don't want to use it for core specific libraries since that area can be used on all cores.
For example, If you have a library that says it works on all cores but really doesn't,
that can create a library that gets used for a core that doesn't work or perhaps doesn't even compile.
But that typically doesn't cause duplicate library messages.
Those usually are spit out by the IDE when there are multiple libraries of equal priority installed in different directory names. i.e. you have a library called "foo" that has header called "foo.h" and the code for that library is installed in two different places, perhaps in directory called "foo" and "foo2" etc...

I'm not sure what is going on with your system/environment, as you have not provided quite a bit of information.
i.e. IDE version, where it is installed, where your sketchbook is located, and what libraries have been installed in which locations.

And a full sketch directory tree of a sketch that is having these issues.

--- bill