Non penso che ci sia davvero un approccio intrinsecamente migliore. Ho visto alcuni approcci alla situazione e il meglio che posso fare è condividere quello che sono:
Cartella di inclusione condivisa
In questo caso hai una cartella globale "Include" che definisce costanti e tipi e funzioni potenzialmente esterne che potrebbero essere esposte ad altre applicazioni. La struttura sarebbe simile a questa:
Solution
project1 (library)
build
src
include
project2 (executable)
build
src
include
I file make aggiungerebbero l'inclusione globale e la libreria include (se necessario) come include le directory in modo che il compilatore possa trovarli esattamente come faresti per qualsiasi libreria. NOTA: il riferimento al file effettivo sarebbe #include "filename.h" . I progetti Automake con i sottoprogetti utilizzano essenzialmente questo approccio.
Progetto condiviso
Questo è lo schema che hai suggerito nella tua domanda. In sostanza hai l'equivalente di
un progetto per i file di intestazione condivisi. L'unica modifica suggerita che farei alla tua soluzione sarebbe il modo in cui fai riferimento ai file di inclusione. Invece di #include "..\..\shared\src\xyz.h" preferirei vedere il percorso di inclusione appropriato passato al compilatore. Visual Studio rende tutto ciò abbastanza semplice, fornendo un elenco di tutti i percorsi di inclusione nel file di progetto. Se crei i tuoi file Make o usi uno strumento per generarli, la chiamata al compilatore richiederà i parametri appropriati (comunemente -I o /I seguito dal percorso).
Sono fondamentalmente uguali
A questo punto è davvero una questione di preferenza, e quale IDE ha il miglior supporto da gestire. Ho visto i file comuni appena lasciati nella directory radice della soluzione, ma quell'approccio è un po 'troppo ambiguo dal momento che non hai alcun contesto per questi file. La linea di fondo è che stai pensando sulla strada giusta.