I have the following sort of directory structure:
part1
build
src
part2
build
src
Now I have a header file that I would like to include in both parts of these projects, it will contain constants and some macro definitions as well as some utility functions, and I want these to be synchronized between the two parts. What would be the generally acceptable way to format my directory structure?
Something like so?
part1
build
src
part2
build
src
share
src
and set up my make files in the build directories to also look in ../../share/src
Or is there a more “correct” way of doing this?
0
That’s how I’ve done it in many projects.
Dare I say “self-documenting”?
It makes it completely clear to anyone looking at this what’s going on.
And that includes you.
Imagine yourself going off to work on some other, completely unrelated project for three/ four years and then coming back to this one. All those little snippets and assumptions and “understandings” that you work with day-in, day-out, today will all be long forgotten. it’ll be like coming to this code completely cold. It’s not nice finding hidden “nasties” in code, is it? So; try not to leave any for yourself.
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 "....sharedsrcxyz.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.