Vs2008 C++: how can I make recursive include directories?

Question

I am including a complicated project as a library in C++ using Visual Studio 2008.

I have a set of include files that are scattered throughout a very complicated directory tree structure. The root of the tree has around ten directories, and then each directory could have multiple subdirectories, subsubdirectories, etc.

I know that all the header files in that structure are necessary, and they are hopelessly interlinked; I can't just include one directory, because then dependencies in another directory will feel left out and cause the compiler to crash in their annoyance at not being invited to the party. So, everyone has to be included.

I can do this by adding the directories one at a time to the project (right click->properties->additional include directories), but that can be fraught with pain, especially when one of the dependencies has children and makes a brand new subsubsubdirectory.

Is there a way to specify an include directory in a header file itself, so that I can just include that header whenever I need to use the functions it contains? That way, I get an easier way to edit the include files, and I don't have to make sure that the debug and release versions agree with each other (since the properties right click defaults to the current build, not all builds, a feature that has led to much crashing when switching from debug to release). Even better, is there a way to point to the directory root and force everything to be recursively included?

EDIT for all those replies so far:

I cannot edit the structure of this project. I can only link to it. I don't like the way the code is organized anymore than anyone else seems to, but I have to work within this constraint. Rather than spending potentially hours in the error-prone process of finding all the interdependencies and putting them in a project file, is there a way to do this programmatically?

Answer 1

If in any way possible you really should take the time to rework that mess. It will only get worse.

If you are including it as a library then you probably only need a subset of its functionality anyway - make it slowly accessible and usable again step by step.

edit:
And no, there is no recursive include - for good reason. It would be completely uncontrollable from a certain size on and you'd fall over file-name-collisions all the time.
You could hack around the limitation via scripting and the project files, but you really would regret it in the long run.

edit2:
Ok, emergency procedure then. Put the library in its own project and use a short script to generate a line containing the neccessary paths seperated by ; which to put in the project file into the projects .vcproj (which is just an xml-file) under:
VisualStudioProject -> Configurations -> Configuration -> Tool -> AdditionalIncludeDirectories
(at least in VS2005, might differ a bit in later versions).

If you need all the includes in your calling code, you might want to consider wrapping that part in a static library in a seperate project to avoid polluting the rest.

Answer 2

That's clearly not a good idea, really.

These directories are a way to organize the code in logical groups.

 /web
   /include
     /web
       /stackoverflow
         /language-agnostic
         /algorithm
         /database
       /meta
         /bug
         /feature-request
   /src

 /local/
   /include
     /local
       /my-favorites
   /src

Now if I type

#include "exception.h"

What the heck am I trying to include ? Where's that file ? How can I see its content ?

On the other hand if I type

#include "local/my-favorites/exception.h"

Then it's perfectly clear. (and I just have two includes -Iweb/include -Ilocal/include)

And this way, I can have multiple files that have the exact same name and there would be no ambiguity, nifty when you wish to integrate two different 3rd party libraries which both have such a 'exception.h'.

Also note that for clarity, the namespace nesting should reflect the directories organization. So that

file: "web/include/web/meta/bug/exception.h"
namespace web { namespace meta { namespace bug {
  struct exception: std::runtime_error {};
} } } // namespace bug, namespace meta, namespace web

This way it's easy to think of what header you have to include when you want a class.

Also note that, for example if you look at boost, they put headers for 'lazy' programmers, in each directory, which include the headers of all subdirectories

file: "web/include/web/meta/bug.h"
#include "web/meta/bug/file1.h"
#include "web/meta/bug/file2.h"
#include "web/meta/bug/file3.h"
#include "web/meta/bug/file4.h"
#include "web/meta/bug/file5.h"

file: "web/include/web/meta.h"
#include "web/meta/bug.h"
#include "web/meta/feature-request.h"

These includes might also 'pull' names into a more generic namespace with a using directive:

namespace web { namespace meta {
  using ::web::meta::bug::bug;
} } // namespace meta, namespace web

To make it less painful for developers.

So as you can see, the language already provide you with a very good way of organizing your code cleanly, if you go with the 'all includes' options, you'll just end up with an unmaintainable mess:

#include "exception.h"
#include "bug.h"
#include "myString.h"
#include "database_connect.h"
#include "helper.h" // really love this one...
#include "file.h" // not bad either eh ?

I've had some of these at work... think 20 unqualified includes when you depend on 25+ components... now, do you think that it would be possible to remove a dependency on component X ? ;)

EDIT: How to deal with 3rd party library ?

Sometimes a 3rd party library does not live up to your expectations, whether it is:

• not self-sufficient headers (ie you need to include 3 files to use 1 object)
• warnings at compilation
• header organization problem

you always have the opportunity to wrap them in headers of your own.

For example, say I have:

/include
  /file1.h
  /file2.h
  /detail
    /mustInclude.h
    /exception.h

And anytime you wish to include a file, you have to include 'exception.h' BEFORE and 'mustInclude.h', and of course you have the problem that it is difficult to spot that the files included come from this 3rd party library and not your own (current) project.

Well, just wrap:

/include
  /3rdParty
    /file1.h (same name as the one you would like to include, it's easier)

file: "/include/3rdParty/file1.h"

#pragma push
// ignore warnings caused
#include "detail/exception.h" // necessary to include it before anything
#include "file1.h"
#include "detail/mustInclude.h"
#pragma pop

And then in your code:

#include "3rdParty/file1.h"

You have just isolated the problem, and all the difficulty now lies within your wrappers files.

Note: I just realize that you may have the problem that the 3rd party headers reference each others without taking the 'relative path' into account, in this case, you can still avoid the 'multiple include' syndroms (even without edition), but that might be ill-fated.

I suppose you don't have the opportunity not to use such crap :x ?

Answer 3

Q: I cannot edit the structure of this project. I can only link to it. I don't like the way the code is organized anymore than anyone else seems to, but I have to work within this constraint. Rather than spending potentially hours in the error-prone process of finding all the interdependencies and putting them in a project file, is there a way to do this programmatically?

This should get you started:

1. write a script (in your favorite "quick" language) to enumerate all the [sub-...]directories in the library directory

2. filter the directories (for start, remove the ones that don't contain any .h files)

3. output them either to header file as you described or directly to the vcproj file. The vs2008 vcproj file is relatively simple XML. It might even be documented, but if you just view it in a text editor, you'll figure out where and how the include paths are defined

4. try to compile

5. if errors, try to figure out why, adjust directory filter (blacklist specific directories etc.) and go back to 2.

6. success

Anyway, don't be afraid to write code generation scripts