No such file or directory when including file from different directory than the sketch file

Hello,

I need to include library file which is in a different directory than the sketch file. I am getting this error: No such file or directory. I do not know why Arduino IDE do not see this file. The path is correct and it should work! It looks like they have an error in Arduino code. I am using Arduino IDE 1.8.19

Does this work in newer Arduino IDE? Or in older one?

Thank you.

How do you refer to that library and where is it stored?
The IDE generates a copy of the project files in a temp dir, so if you pointed to the file with a relative path, then it’s not going to work.

The easiest way is to store your library in the library folder or make a copy in the sketch’s folder

I am using relative path: #include "../Console/Console.h"
I have my project on a flash drive. The relative path should work this way.

No…read again the first answer

Will they repair it?

It’s not broken
That’s the way the IDE is designed

Why don’t you just put your library where it belongs if you want to use he IDE?

Put your library files in a subdirectory (below your arduino code) called "src"

Then it is not good designed. I understand that Arduino is just a free tool for home projects but look at this directory structure:

F:\MyProjects << root
F:\MyProjects\Buttons << library component
F:\MyProjects\Console << library component
F:\MyProjects\Network << library component
F:\MyProjects\App1 << sketch #1
F:\MyProjects\App2 << sketch #2
F:\MyProjects\App3 << sketch #3

The App1, App2 and App3 are standalone sketches which use my own library components. All is placed in one folder I can copy, archive, rename etc...

Arduino IDE does not allow this? The proposed solution you write about:

  1. place all components in predefined Arduino library directory - but I do not want to copy all my components to directory like this. To do this on every computer I am working with. Then if I make a change in one of my component, I have to re-copy everything again (and do not forget it).
  2. place all components in subdirectory of every sketch - components has to be centralized on one place. This is even worse than point 1 - because if you make a change in one of my component I have to re-copy it to all sketches.

I assume I am not the only one who prepares his projects like this.

That’s a design decision they made that you can disagree with. It does make the life of beginners simple

Since the compilation does not happen in the directory you have but somewhere else in a temp directory, the relative links do not point at the right place and the command line used by the IDE defines the search path (local dir and library dir) which will not include your own “library” location.

See this discussion for example and post 7

If you move the libraries under F:\MyProjects\libraries then you can set the "Sketchbook location" preference in Arduino IDE to F:\MyProjects.

It will then be possible to use the usual #include directive format in your sketches:

#include <Console.h>

But flash drive can be mapped as F, or D etc... I often create backups (of projects and libraries) that I return to. "Hardcoded" path is not good solution.

I do not know why the developers of the Arduino IDE decided that. C/C++ solution exists for this and is flawless so why not use it? I do not think it is any easier for beginners - seeing how many threads there are on the internet about this problem.

Not totally.

the .ino sketch files are not the final files that get compiled. They get pre-processed (combined together in a .cpp file, the main() function is injected, prototypes for forward declarations are added, libraries are processed to find the most suitable candidate when you have multiple ones with the same .h etc).

They decided to do this in a temp directory rather than clutter the project directory.

That's the part supposed to help the beginners so that they can just focus on setup() and loop().

I understand the process but do not see the benefit of this - only limitation. I mean both (absolute and relative path) should work together without problem. The compilation has nothing to do with it - even if the Arduino compilation will be performed on the moon, the local link to the external file must work anywhere.

No... first of all the local relative link is just to the .h, you need to find the .cpp as well (and possibly a host of other files) which is what the IDE does with include path and some "magic"

but it's relative, and since the compilation happens on a copy, the fact that it's on the moon (the sketch has been copied to another location ) does matter

Assume your sketch is in

F:/A/B/C1/D/sketch/sketch.ino

and a library in

F:/A/B/C2/header.h
F:/A/B/C2/header.cpp

and that your sketch refers to

#include "../../../C2/header.h"

when you hit the compile button a copy of

F:/A/B/C1/D/sketch

is created say in

C:/tmp

so you have

C:/tmp/sketch/sketch.ino

and thus ../../../C2/header.h does not refer to anything anymore

--

Yes I agree it's annoying but that's how it has been designed.....

have you tried suggestion from @ptillisch in post 10?

I do not understand why Arduino IDE do not change relative paths to absolute first, than copy the sketch into temporary directory and ... MAGIC ... all works. I see it as a bug that has no reason to exist.

But of course I can live with that - but it is not correct solution.

indeed - that was the point made by @Robin2 in the post I linked above

but still worth reading post 7

it's not because the C++ pre-processor found the .h that the compiler knows where all the dependencies you need to compile and link with your code are

sometimes wish for makefiles to have been chosen to handle this...

There's nothing you can do about it: that's just the way the IDE works. If it's an issue, then use a different IDE like VS Code + PlatformIo that does things in a more "standard" way.

the GNU AVR tool chain is accessible. there's nothing preventing you from creating you own build scrip using make to compile/link your code and use avrdude to program an arduino