Shared .h and .cpp without installing as a library

My apologies if this is an FAQ. I've got a number of related projects/sketches in a tree of subdirectories which are saved in an on-site VCS (Subversion):

/usr/local/src/arduino-examples$ ls -1a
.
..
Adafruit_INA219
double-tap
double-tap-and-hello
ei_eio_serial
epd2in13-demo
epd7in5b_V2-demo
GxEPD2_Example
mega-sdcard
piconomix
.svn

These are basically demo projects from various places which I don't want to modify other than improving comments (e.g. making sure that physical connection information is near the top of the file) for my own use.

I would like to add a single line in the setup() function to output board information using the hack described in Determining the board type being used, revisited - Programming Questions - Arduino Forum but I would prefer to have the function/macros defined local to this group of projects rather than being global to the IDE.

I've tried

#include "../board_info.h"

with a view to putting the .h and .cpp file "one level up" from the sketches themselves, but the IDE reported that the .h file couldn't be found. If I use an absolute path

#include "/usr/local/src/arduino-examples/board_info.h"

the header file is found but the associated .cpp file isn't compiled/linked. If I move the .h and .cpp files into the same directory as a sketch and put no directory info in the #include directive the sketch builds and runs as expected.

Is there a "correct" way of doing this that doesn't involve installing a library which would be global to the IDE and is more elegant than copying the .h and .cpp to every sketch's folder?

MarkMLl

Your IDE should let you add an include path in the settings.

arduino_new:
Your IDE should let you add an include path in the settings.

That would install it IDE-wide, which is not what I want.

What I want is a strictly "old school" solution with the .h file in the parent directory, if necessary I'll put everything in that file (i.e. rather than also having a function in a .cpp file) but at present I'm having a problem getting the preprocessor to do anything useful with the relative path.

MarkMLl

Fixed using symlinks which appears to be the only way of doing it.

MarkMLl