Library include paths with same header name

Question

What is the best method to include a file that has same name in another folder from additional include directories?

Example:

lib1/include/foo.h
lib2/         


        

Answer 1

I wonder that with the 4 answers and 1709 views at the present moment nobody yet advised such an easy and straightforward solution.

You may include the files as you want, the only real problem that you're going to encounter is about the same guard headers. So, you have to create a header which will include both the conflicting header files. Let's call it inc_foo_lib1_lib2.h. In this file you include the first foo.h, then if the guard header was defined undefine it, next include the second foo.h.

As an example suppose that the foo.h have a header guard FOO_H_INCLUDED, then your inc_foo_lib1_lib2.h is looks like:

#include "lib1/foo.h"
#ifdef FOO_H_INCLUDED
#undef FOO_H_INCLUDED
#else
COMPILATION ERROR — the header guard was changed!
#endif //FOO_H_INCLUDED
#include "lib2/foo.h"

Answer 2

#include "lib1/include/foo.h"
#include "lib2/include/foo.h"

Is fine as long as this is the actual relative path to those headers and the include guards are different. For example, if both foo.h use

#ifndef _foo_h_

then this will give you something you dont want (it will only include one, not both and which one depends on the order of execution).

Answer 3

I would include the files from a unambiguous directory which is in the -I list (That is to say the path to the directory which contains lib1 and lib2):

#include "lib1/include/foo.h"
#include "lib2/include/foo.h"

Therefore there will be no ambiguity because the precompiler will look at lib1/include/foo.h within its directory list and that don't happen from lib1/include/ or lib2/include/ but only from the parent directory.

As said earlier: take care with the guards, even if for a lib header, the name should include the lib name to avoid such confusions.

Answer 4

You can just do this:

#include "lib1/include/foo.h"
#include "lib2/include/foo.h"

and make sure that the parent directories of both lib1 and lib2 are in your search path for includes (but not the actual include subdirectories themselves).

Note that if both headers use the same symbol as an include guard then this method will not work - you would need to undefine the conflicting symbol between the two includes:

#include "lib1/include/foo.h"
#undef FOO_H
#include "lib2/include/foo.h"

Answer 5

First off, this answer assumes that the include guards for the two headers are compatible (i.e. not the same symbols).

One thing you can do is create links in known locations to the header files of interest, giving the links themselves distinct names. For example, say your two libraries are installed at $LIB1PATH and $LIB2PATH, which could have different values in different build environments. Thus the headers you want to get are at $LIB1PATH/include/foo.h and $LIB2PATH/include/foo.h.

You could go two ways with this. One is by creating direct links. This could look like this in your project's directory tree:

$PROJDIR/
    include/
    lib_include/
        lib1_foo.h -> $LIB1PATH/include/foo.h
        lib2_foo.h -> $LIB2PATH/include/foo.h
    src/

This could get tricky if your code is in a repository, because you couldn't check these links in; they'd be wrong in other environments. Also, if you have a lot of these links and few libraries, you'd have to recreate all of them whenever lib1 or lib2 move... not cool. You can get around this problem by creating links in the directory that contains the project's directory:

$PROJDIR/
    include/
    lib_include/
        lib1_foo.h -> ../../lib1/include/foo.h
        lib2_foo.h -> ../../lib2/include/foo.h
    src/
lib1 -> $LIB1PATH/
lib2 -> $LIB2PATH/

In both cases, you need to make sure $PROJDIR/lib_include is on your include path. Also, you only need to have $LIB1PATH/include and $LIB2PATH/include in your include path if the two foo.h headers pull in more headers from those directories. You could also put the links in include and get rid of lib_include, but I like keeping these things separate.