How to namespace C++ header files?

Question

I use a code with different libraries, which use names like defines.h. This does not only cause conflicts for identical filenames, but also creates confusion. From which library is the defines.h include?

Including as #include <library/defines.h> would be a clean solution, but then the include path would need to be the parent directory of the library, which is rather unclean again. Is there some way to alias the include path, so that -I/path/to/library makes the headers available under library/headername.h?

• Peter: Your description "alias the include path" doesn't make sense.
• allo: Why not? Something like -I/path/to/library:mylibrary and then I can use the files in the folder as mylibrary/headerfile.h, where mylibrary is an alias for the full path.
• Bo Persson: You could create a directory link at the OS level.
• allo: Yes, as a workaround I can create an mylibs directory and put it into the include path and put all libraries there or link them there on unix systems. But the question is, if there is a better way. Java knows hierarchical imports, python uses a hierarchy and aliasing with import foo as bar, but what defines.h is included in C depends on the order of include paths.
• SirDarius: which is rather unclean Not really, since it is exactly how the standard directories such as /usr/include work. Although variations exist, many libraries expect the the include path to be -I/usr/include, so that headers can be included with a unique prefix exactly matching the directory structure.

Answer 1

Is there some way to alias the include path, so that -I/path/to/library makes the headers available under library/headername.h?

There seems to be no need to in this case. You can simply use -I/path/to which makes /path/to/library/headername.h available under library/headername.h.

That said, while there is no such compilation option (that I know of), you can create such "aliases" to file paths in most file systems. These aliases are called symbolic links. In this case, you could make a link /path/to/library/mylibrary that points to . which would make /path/to/library/headername.h available under mylibrary/headername.h assuming you've used -I/path/to/library.

• H Walters: This is at the very least not a complete solution. If headername.h depends on headerutil.h, it typically pulls things in using #include "headerutil.h". With this approach, such dependencies would break.
• eerorika: @HWalters #include "headerutil.h" would not break (not in GCC anyway). If headerutil.h is in same directory as headername.h, then that is the first location where it will be looked for regardless of any include directory options.
• H Walters: Sure, so if you're using GCC you'd be good for intralibrary dependencies using this approach; but how about interlibrary dependencies? e.g., L1's A depends on L2's C, L2's B depends on L3's D, and L3's D depends on L4's C. (Still in this case could add "inclusion order", but this gets messy fast).
• allo: Some libraries already come with a useful directory structure. For example my boost here has in the path where it is unpacked (I am on windows here ...) a subfolder boost. This makes it easy to put the root folder on the include path.
• H Walters: allo Yes; those are libraries set up for such things. In such library headers, L1's A.h would invoke the L2 B dependency using #include "L2/B.h". If you're developing these libraries you can set them up. If not, you could transform the headers, since they're of no semantic significance (the only downside, outside of getting it right, is having to do it each update).

Answer 2

At least on unixy systems, when you compile and install a library, headers are installed for example to

/usr/lib/libraryname/*.h

Or maybe something like

/opt/libraryname-1.2/include/libraryname/*.h

And then if necesssry (not installing to compiler's default include search path), right dir is added with compiler option, for gcc for example option

-I/opt/libraryname-1.2/include

Then just always do this in source code, trusting build system to have included the right search paths:

#include <libraryname/includefile.h>

• allo: I wish I would work on a unixy system. I have here a windows and libraries which are specified in cmake variables as path of a installation or checkout of a repo. This means library/.. can contain all sort of things I would not like to have in the include path. And I have no idea, where the user later will put his libs. The cmake variables are there, so he can have /path/to/somelib-x.y, but I do not know the x.y in advance either.
• H Walters: Whether you have a common or separate directories isn't too relevant. If you I in (-I or /I) a set of base directories, then as far as you're concerned everything may as well be in the same directory (the only difference is inclusion order of shared include paths which, I would argue, you should strive to design your way out of relying on anyway).