I've been working on a library that is intended for projects that use the TinyScreen. So in my library's .h file, I started by saying:

#include <Arduino.h>
#include <TinyScreen.h>

In my test project, I include my library's .h file as well as TinyScreen.h and when I do so, I get a bunch of errors saying that I'm redefining stuff. However, if I remove it and instead rely on its inclusion in the test project, I get errors indicating that TinyScreen does not name a type. And if I add the #include <TinyScreen.h> in the library's .cpp file, I still get the "does not name a type" error.

What am I doing wrong? What's the right way to approach this?

[TinyLibrary.h]

The reason you get the redefine error is because your library header file is including TinyScreen.h AND your app ino file also include TinyScreen.h. It can only be included once.

Consider this example.
We have a file called TinyLibrary.h with the content:

Code Select Expand

const int tinyLibraryVariable = 12;

Then we have another file called MyLibrary.h with the content:

Code Select Expand

#include <TinyLibrary.h>
int myLibraryVariable = tinyLibraryValue;

You will then get the redefine error if you create a myapp.ino file that looks like this:

Code Select Expand

#include <TinyLibrary.h>
#include <MyLibrary.h>

The reason why you get the redefine error message is because MyLibrary.h is including TinyLibrary.h, but TinyLibrary.h was already included from myapp.ino

So you have three options to solve this:
1) Do not include TinyLibrary.h from MyLibrary.h
2) Do not include TinyLibrary.h from myapp.ino
3) Write TinyLibrary.h in a way so it doesn't redefine symbols if it has already been included

Option 3 is generally the correct way forward, but since that code is out of your control it may be difficult. (I will create a pull request that address this issue later today, but I don't know how long it will take for TinyCircuit to integrate it in their source)

In my example above MyLibrary.h needs to have the symbol tinyLibraryVariable so TinyLibrary.h needs to be included either before MyLibrary.h is included, or at the top of MyLibrary.h. If you don't intend on distributing your library it doesn't really matter which option you go for.

Hi! Yes, I understand the basic mechanics, but since my library is built "on top of" TinyScreen, it needs it included. I understand why I get the re-defines when including it, although the usual means of fixing that is to use "include guards" in your header, e.g.:

#ifndef MYUNIQUELIBRARYSYMBOL

// include the meat of the header here...

#define MYUINQUELIBRARYSYBOL

#endif

And I believe if TinyScreen were done that way, it would solve my problem (guess I should test that theory!).

Anyway, lacking that, I did remove the #include from my library, and put it in my project, ahead of the inclusion of my library, but it still failed then with the "doesn't name a type" error. I'm guessing it's something to do with how they compile libraries, but don't know for sure.

Sorry, it's difficult to assess how much people know when answering a forum post like this.

I doubt that a library file (.a file) is actually built. There is no need or gain from building a library file and it is more complex to do so and link that library file into the app compared to simply compiling the cpp files into object files and linking them.

So with that in mind, there is probably nothing weird going on.

I would guess that including the tinyscreen-header at the top of your ino file, AND including it at the top of the cpp file for your library would do the trick perfectly, since by doing so the same header file would not be included twice in the same cpp file. (Or you could add the include guards in the tinyscreen header file to avoid redefining the symbols in case the header file would be included twice)

...
I would guess that including the tinyscreen-header at the top of your ino file, AND including it at the top of the cpp file for your library would do the trick perfectly, since by doing so the same header file would not be included twice in the same cpp file. (Or you could add the include guards in the tinyscreen header file to avoid redefining the symbols in case the header file would be included twice)

Thanks for reminding me that the include issue should be a "once per compilation unit" problem. Finally, thanks to your prodding, I realized that in my library's .cpp file, I had my includes in the wrong order -- I first had the library's .h file, so naturally, the "TinyScreen" type was unknown at the time. Once I put TinyScreen.h first, those errors went away.

Wohoo!