I don't think there really is any inherently better approach. I've seen a few approaches to the situation, and the best I can do is share what they are:
Shared Include Folder
In this case you have one global "Include" folder that defines constants and types and potentially external functions that would be exposed to other applications. The structure would look like this:
Solution
project1 (library)
build
src
include
project2 (executable)
build
src
include
The make files would add the global include and library includes (as necessary) as include directories so the compiler can find them just like you would for any library. NOTE: the reference to the actual file would be #include "filename.h". Automake projects with subprojects essentially use this approach.
Shared Project
This is the outline you suggested in your question. Essentially you have the equivalent of
a project for shared header files. The only suggested change I would make to your solution would be how you reference the include files. Instead of #include "..\..\shared\src\xyz.h" I would rather see the appropriate include path passed to the compiler. Visual Studio makes this pretty easy to do, by providing a list of all the include paths in the project file. If you create your Make files or use a tool to generate them, then the call to the compiler will need the appropriate parameters (commonly -I or /I followed by the path).
They are basically the same
It's really a matter of preference at this point, and what your IDE has the best support to handle. I have seen the common files just left in the root directory of the solution, but that approach is a bit too ambiguous since you don't have any context for those files. The bottom line is that you're thinking down the right path.
