Multiple Libraries

I have several different sensor libraries for a common sensor… and I have several different sketches that use the same sensor. My question (finally) is how do I organize or use the different Lib’s to avoid compile time errors in trying to compare functionality vs code size or just because I’m too lazy to rewrite all the different prior code ‘sketches’ for a common library.
My solution so far has been to place the class library in the sketch… folder, copied from the library that resides where it should \sketchbook\libraries… and use #include “XXX” instead of #include
More specifically in this case (there are several others) I have 3 different ‘lib’s’ for the DHT sensor and in an effort to evaluate them for functionality and code size because I am interested in the Tiny’s I ran into a confusing ‘brick wall’.
Is my solution the correct one or is there a better method for using multiple common sensor lib’s in different applications.
In writing Arduino applications when I get a piece of a sketch that can serve as a ‘module’ I do just that. I save the ‘module’ and use it as a function in future applications of the sensor involved.
The real issue manifests itself when I write a new sketch involving a different lib for the same sensor. In this case it’s the DHT sensor but there are several different other sensors that create the same conflicts at compilation time due to multiple lib’s with common file names.


It is either patching your sketch to match the lib or the other way around. Problem with searching for a minimal sketch is that lib builders tend to do the opposite - add stuff -

My way of handling is first get a lib that works and then try to strip it to the functionality needed. E.g. for the DHT11 you could create a lib version that does not do CRC check, no errorhandling and only returns humidity.

Then there is the fact than some libs are bigger when used for 1 sensor, break even at 2 and are smaller when used for 3 sensors when compared with other sensor.

Thank You, As a matter of fact I'm using your DHT lib class and it was most easy to figure out what to omit. I thank you for writing code that is to purpose rather than 'One Size Fits All" code. My issue is a little different. I have several classes that share only name and purpose and unfortunately the compiler can't read minds (yet) and it merrily uses the first class that it finds with the same name. I've also learned the hard way that nothing not directly related to compiling a piece of code should go in a 'sketch' directory. It took me several hours to find this some time back and it cropped up again in trying to compile a much abbreviated version of your sample code. The compiler thought that the Adafruit DHT class was a much better fit? and then kept objecting to pieces of it. My intent is to find or deduce the best method that will allow me to keep different class version by different authors in my library folder and be able to use them as well. I might add that it would also be nice if one could pick and choose different methods from a class W/O rewriting the class. I am told however that Popsickle Stands in the nether regions are more likely. Now I also have good reason to believe that piece of disappointing news..


rename them is the only way to go then
#include <ada_dht.h>
#include <rob_dht.h>
#include <another_dht.h>

I have had similar problems with I2C LCD libs, and in the end I just moved all the libs not used to a _libraries folder in which I also put the libs I want to investigate (e.g. download stuf). I had the idea that it kept the compiler happier too :wink:

Rob you must have heard my vocal aggravation I tried renaming the other files, not the ones I was using… What happens with the .cpp files?
DHT.h calls DHT.cpp…? This is one area (of many) where I don’t have a clue and I don’t remember reading about it in any of the Arduino or C/C++ books I have/am reading.
How does renaming the header file affect the compilation process?.
My “solution” was to put the put the header and CPP files in the sketch directory and write #include “XXX.h” instead of #include <XXX.h>. It isn’t anything that I’d read from a textbook but rather something I’d seen in an Adafruit example.
The really great thing about hacking someone elses code is all the neat things that I learn along the way. I learn to write and I get a LOT of neat stuff for my growing “Macro” folder. When I pushed electrons around for a living I had 2 things that were vital. #1 was my footprint libraries, both Schematic and PCB and my circuit scrapbook.
The circuit scrapbook was uniquely valuable because it also held my design notes for the circuit, the circuit’s source and any other pertinent notes to re-use and source or required permissions.
Some lessons are never forgotten.


A simple library will have this structure:

  Folder: foo

Now in your program you have:

#include <foo.h>

If you need to make a similar copy, you need to rename all 3 x foo in the above. Folder, .cpp and .h files. Example:

  Folder: myfoo

If foo.cpp includes foo.h (which it probably will) then you need to amend that line in foo.cpp as well.