#include a standard library in a custom library

Hi All,

Is there a way to #include a standard library from a custom library without copying the standard sources to the custom library folder?

The #include statement can include relative paths, so, yes, you can do this.

Bear in mind that the compiler searches the sketch to see what to compile, so if only your library is included in the sketch, only your library will be compiled, and the other library will not.

Thanks for your reply PaulS,

What if I just want to #include LiquidCrystal.h without knowing where it lives?

If i do this:

#include <LiquidCrystal.h>

, then the compiler complains that it cannot find it, so I have to copy LiquidCrystal.h and LiquidCrystal.cpp to my custom library folder and use:

#include "LiquidCrystal.h"

Is there a nicer way?

What if I just want to #include LiquidCrystal.h without knowing where it lives?

You can't.

so I have to copy LiquidCrystal.h and LiquidCrystal.cpp to my custom library folder and use:

No. This implies that you do know where LiquidCrystal.h lives.

You library and LiquidCrystal should have the same parent. So, you should be able to

#include <..\LiquidCrystal\LiquidCrystal.h>

in your library.

In your sketch, you need

#include <YourLibrary.h>
#include <LiquidCrystal.h>

PaulS, thanks again for your reply - I understand there is no nice way - as my library lives in \libraries\MyLibrary and LiquidCrystal.h is in \libraries\LiquidCrystal.

So I have to either include LiquidCrystal.h in the sketch, or include it in MyLibrary.h and copy LiquidCrystal sources to \libraries\MyLibrary.

The need to include LiquidCrystal.h in the sketch is not dependent on where the LiquidCrystal library is relative to your library. It MUST be included in the sketch.

You can not hide from the sketch the fact that you are using LiquidCrystal.

PaulS,

Apologies, perhaps I have not explained it correctly.

The library has a class that inherits LiquidCrystal, so I thought it would be better to include LiquidCrystal header into MyLibrary.h

The way I found to hide LiquidCrystal.h from the sketch is to:

  1. Copy LiquidCrystal.h and .cpp to MyLibrary folder
  2. in MyLibrary.h add:
#include "LiquidCrystal.h"

Is this not considered good practice?

Is this not considered good practice?

No it isn't. The reason is that any computer that gets your library installed on it now has two copies of LiquidCrytal.h and LiquidCrystal.cpp.

While this may not seem like a big deal, what happens if the LiquidCrystal library gets updated? Now, the two copies are not the same. A sketch that uses LiquidCrystal (why couldn't that have been called LQ? Much easier to type) and needs the new behavior will work, until the owner tries using your library.

Consider, too, what happens if someone wants to derive from your library. Now, there need to be 3 copies of LiquidCrystal on the computer.

Soon, it becomes a nightmare to try to keep all the copies of LiquidCrystal up-to-date.

In my opinion, it is better to be up front about that fact that your library depends on LiquidCrystal.

Hi PaulS,

I see your point and "I cannot fail to disagree with you less" :wink:

(4 negations = total agreement)

I will make the changes you suggested.

Thank you for your valuable input.

It could have been better though - I still don't like the fact that I have to include LiquidCrystal.h using the absolute or relative path.

The LiquidCrystal library inherits the Print class from core library:

#include "Print.h"

My understanding is that my library cannot do:

#include "LiquidCrystal.h"

only because LiquidCrystal is not in the core libraries and therefore cannot be found at compile time. It would have been nice if the path to non-core libraries such as LiquidCrystal was included in the default library search path at compile time.

Perhaps this can be corrected in future versions of Arduino software? Or is there a better way?

You can include the depended-on library from the sketch as well as from your library, then it will be included in the search path.