Is there such a thing as too many include paths?

Question

In an attempt to organize my code base I have been moving my files into a hierarchy of folders e.g.:

• Folder A
  • Folder AA
    • Foo.cpp
    • Foo.hpp
• Folder B
• Folder C
  • Folder CA
    • Bar.cpp
    • Bar.hpp
• Folder D
• Folder E

While it has made finding individual files easier, it has made referencing them more difficult. For Bar.cpp to reference Foo.hpp I have to put a relative path to the header file:

#include "../../Folder A/Folder AA/Foo.hpp"

Initially I did this every time I needed to reference a file but it not only looks rather ugly it is also really fragile. Anytime I decide to reorganize files it would break every reference to that file.

To fix this, I'm considering adding an include path (-I) so that the above include statement would be reduced to:

#include "Foo.hpp"

Is there going to be a significant performance hit on compiling if I add include paths for every folder in my folder hierarchy (I have around 9)? Is this a good practice at all? What do people in industry do in this situation?

Answer 1

I don't think there are any single way of solving for this, however the betst working solutions I have seen are;

1. Yours. As you describe, simply leave the header file with the source code, and have the Makefile have all the directories listed in a -I option -- there is not really any noticeable performance issue with compiling. The issue is with Maintaining the list in the makefile but that can be automated with some macros if that is needed.

2. Keep the .h file with the source code and symlink all .h file to a /include directory in your project. You can automated the symlink as an initial step of your Makefile so that you don't have to keep that up-to-date.

In either case project convention is important, so if your project does not have to integrate with anything you are free to do what you want, but if you are making a package for some other system, you should follow whatever convention they have already set out.