Libraries Sometimes Not "Seen" By Compiler

I’ve had recurring problems with some of my libraries being unrecognized under some circumstances, and I’m kinda baffled as to why. First, this only seems to occur with “private” libraries in /Users/RayL/Arduino/libraries, and only when they are referenced by other libraries also within /Users/RayL/Documents/Arduino/libraries. I can reference them just fine from sketches in /Users/RayL\Documents\Arduino\xxx.

I’m using the latest AtmelStudio, with VisualMicro.

As an example, I have one library, HBridge50A. I can create a new project, and use this library as:

#include <HBridge50A.h>

HBridge50A *HBridge;

void setup()
{

HBridge = new HBridge50A();

}

But, the exact same code, when used in a test program for another library object, gives this error:

Compiling ‘HBridge50ATest’ for ‘Arduino Mega 2560 or Mega ADK’
Build folder: file:///C:/Users/RayL/AppData/Local/VMicro/Arduino/Builds/HBridgeDriverTest/mega2560
HBridge50ATest.ino:25: error: expected constructor, destructor, or type conversion before ‘*’ token
HBridge50ATest.ino:In function ‘void setup()’
HBridge50ATest.ino:78: error: ‘HBridge’ was not declared in this scope

What has me baffled is that some libraries work fine, and some don’t, and I can’t see ant difference between them.

I notice that in the build folder, each working library object has a sub-folder which contains .o files for that library. No such folder is created for the failing libraries. So, it appears the compiler is simply not “seeing” the library source folder. But why?

Any ideas?

Regards,
Ray L.

Quite often the compiler doesn't find a library for one of two reasons: 1) the library isn't in the right Arduino subdirectory, or 2) it is in the libraries subdirectory, but the IDE was not restarted after the library was copied.

Problem one is solved by locating the libraries directory off the main directory where you installed the Arduino IDE. So, if you have the IDE installed in a directory named:

C:\Arduino156

then the proper place to put a new library is in the subdirectory found at:

C:\Arduino156\libraries

Once you have the new library copied to the libraries subdirectory, you need to reload the IDE. Also note that sometimes the library doesn't expand to the proper library name. That is, you might have a library named SuperHotLibrary100, which unzips to SuperHotLibrary100\SuperhotLibrary100. But when you look in the subdirectories, you find:

SuperHotLibrary100\SuperHotLibrary100\SuperHotLibrary\ Examples SuperHot.cpp SuperHot.h keywords

In this case, you want to copy the subdirectory named SuperHotLibrary to the libraries subdirectory of the Arduino IDE, NOT SuperHotLibrary100.

Looks like you nailed it. A simple restart, and it's now being much more cooperative.

Thanks!

Regards, Ray L.

then the proper place to put a new library is in the subdirectory found at:
C:\Arduino156\libraries

That is not my understanding. User contributed libraries belong in the libraries folder in the folder where programs are stored according to http://arduino.cc/en/Guide/Libraries

That is not my understanding. User contributed libraries belong in the libraries folder in the folder where programs are stored according to http://arduino.cc/en/Guide/Libraries

First, the document states:

Starting with version 1.0.5, you can install 3rd party libraries in the IDE.

If you read the examples given there, where they are really placing the library is the same place I mentioned after the base directory. Their example:

My Documents\Arduino\libraries\ArduinoParty\ArduinoParty.cpp My Documents\Arduino\libraries\ArduinoParty\ArduinoParty.h My Documents\Arduino\libraries\ArduinoParty\examples

Given that I always place the IDE in its own base directory, using Arduino156 instead of tucking it away in My Documents, we have: My Documents\Arduino\libraries\ArduinoParty\ArduinoParty.cpp which becomes Arduino156\libraries\ArduinoParty\ArduinoParty.cpp on my system. I think my setup just makes it a little easier to find things.

First, the document states: Quote Starting with version 1.0.5, you can install 3rd party libraries in the IDE.

True, but what it means (and explains) is that you can install the libraries from inside the IDE. It goes on to say

The zip file will have been expanded in the libraries folder in your Arduino sketches directory.

Given that I always place the IDE in its own base directory, using Arduino156 instead of tucking it away in My Documents

Agreed, putting the Arduino directory within My Documents would be silly, but that is not what is being advocated.

Putting user contributed libraries in a folder in My Documents/Arduino means that they are available to all versions of the IDE and do not need to be moved or copied when the Arduino software is upgraded. You can even use several versions of the IDE on the same PC with no changes to the library setup.

Makes sense. I didn't get that when I read it, but I can see the advantage of that layout.

It would make even more sense if there weren't 2 libraries folders in the first place of course.

OK, here's a related question.... Handling of include files in libraries seems..... bizarre. Here is an example:

I have several libraries: HBridgeDriver, PID, QuadratureEncoder, PIDServo. The PIDServo library creates object instances of the other three types. PIDServo.h begins with #include for the .h files for HBridgeDriver, PID, and QuadratureEncoder. But, when I try to compile a sketch that creates an instance of PIDServo, I get errors for every reference to the other objects. The exact error is, for example, "ISO C++ forbids declaration of 'QuadratureEncoder' with no type". If I put #includes in the sketch for all the lower-level objects, then all is well. But, as I said, the very first thing in PIDServo.h is #includes for all of those other objects, so why is it necessary to repeat them in the sketch? Why is the compiler not "seeing" those same #includes in PIDServo.h?

Regards, Ray L.

First, the document states: Quote Starting with version 1.0.5, you can install 3rd party libraries in the IDE.

But does this not then require a lot of extra user file management manipulation when you want or need to upgrade to the next IDE version that comes out? Having 3rd party libraries installed in the user's sketch directory was a much improved upgrade when first implemented and works great and requires no user work when upgrading the IDE. Remembering to close and reopen the IDE is the only rule one has to be aware of when adding new library files.

But does this not then require a lot of extra user file management manipulation when you want or need to upgrade to the next IDE version that comes out? Having 3rd party libraries installed in the user's sketch directory was a much improved upgrade when first implemented and works great and requires no user work when upgrading the IDE.

I have never used the IDE to install a library having always added them manually but if you look further on the page about installing libraries using the IDE it gives an example and says

The zip file will have been expanded in the libraries folder in your Arduino sketches directory.

So it is where we seem to agree that it belongs.

UKHeliBob:

But does this not then require a lot of extra user file management manipulation when you want or need to upgrade to the next IDE version that comes out? Having 3rd party libraries installed in the user's sketch directory was a much improved upgrade when first implemented and works great and requires no user work when upgrading the IDE.

I have never used the IDE to install a library having always added them manually but if you look further on the page about installing libraries using the IDE it gives an example and says

The zip file will have been expanded in the libraries folder in your Arduino sketches directory.

So it is where we seem to agree that it belongs.

I too have never used that new method and also agree all is well in the arduino world as the added libraries do end up in the proper place, in a libraries folder in the user's sketch directory. I'll have to remember to try this new method as I presently am using 1.0.5r2.

But, as I said, the very first thing in PIDServo.h is #includes for all of those other objects, so why is it necessary to repeat them in the sketch? Why is the compiler not "seeing" those same #includes in PIDServo.h?

Turn on verbose mode for compiling. With the #include statements in the sketch, look at what gets copied to the build time folder.

Then, comment out the #include statements in the sketch, and see what gets copied to the build time folder.

Not the same set of files, is it?

Having done that, perhaps you'll understand why the libraries all need to be listed in the sketch. If not, think how difficult it would be to find all the libraries needed if each library was free to include other libraries that you didn't have. If the examples at least need to list ALL the libraries needed, you'll know, when you start trying to use one of them what it depends on.

I guess the build process must be more different from what I'm used to than I thought. I did what you suggested, but still don't understand why it works like that. But, then, I don't understand how the build process works in any detail at all.

But, if I have to put in redundant #includes, so be it. At least now I know what to do.

Thanks!

Regards, Ray L.

But, if I have to put in redundant #includes, so be it. At least now I know what to do.

That's the spirit.

Actually, the problem is that the IDE parses the .ino file(s) looking for #include statements. The included files are in known directories. The contents of those directories are copied to the build directory. The .h files included in libraries that are copied to the build directory are not looked at. So, if a sketch references libA.h, and libA.h includes libB.h and libC.h, only libA.h (and libA.cpp) will be copied to the build directory. When libA.cpp is compiled, libB.h and libC.h are nowhere to be found (in the build directory), so it will fail to compile.

Include libB.h and libC.h in the sketch, and they (and the cpp files) will be copied to the build directory, so libA.cpp will compile.

Yes, copying stuff all over the place was a dumb idea, but it doesn't seem like you can tell the Arduino team anything.

Paul,

OK, that makes sense. Well, really, not it doesn't, but I now understand the issue. People always seem to do weird things when they create "smart" build systems, and this one is far from the worst I've seen over the last 30+ years.

Regards, Ray L.