Is there a way to tell the g++ compiler, not to look for include header in a certain -I path?

1
votes

I'm trying to compile a cpp file that uses include headers from 2 folder locations. Both the folders has lot of headers that are necessary for my file.

Now, one of the header file is present in both the folders, but the problem is they are of different version. Hence the functions in that common header have same name but different API signature.

Something like this:

Folder A:

  • foo.hpp
  • bar1.hpp
  • bar2.hpp
  • bar3.hpp

Folder B:

  • foo.hpp
  • bar4.hpp
  • bar5.hpp
  • bar6.hpp

API of function foobar from foo.hpp of folder A: void foobar(arg1, arg2);

API of function foobar from foo.hpp of folder B: void foobar(arg1, arg2, arg3);

#include "foo.hpp"
#include "bar1.hpp"
...
#include "bar4.hpp"
...
...

int main(){
...
foobar (arg1, arg2);
...
}

g++ main.cpp -o MyExe -I< path-to-folder-A > -I< path-to-folder-B >

This throws the errors like multiple redefinition of function, no matching function call etc., for various functions in the header.

So, my question is: Are there any flags to tell the compiler only to consider the definition found from folder A and ignore the one from folder B?

Note on code limitations: I cannot alter the folders or files of A and B in any manner. Neither can I give absolute paths to the headers instead of -I.

2
c++gccg++
Even if it was possible, your proposed solution won't work for very obvious reasons. Each header file in each directory expects and requires its own foo.hpp, from the same directory. As such, waving a magic wand and making one of them disappear won't work. You will have to split your code into different source modules and compile them separately, with each module using one of the -I options. And, of course, there is no guarantee that the resulting frankencode will link correctly, but that will be another problem you will need to solve at some point. – Sam Varshavchik
Can you guarantee that all those headers have manual include guards (#ifndef MY_HEADER etc.)? – Max Langhof
"Note on code limitations: I cannot alter the folders or files of A and B in any manner. Neither can I give absolute paths to the headers instead of -I." SOL then – Lightness Races in Orbit
There is no solution - you would to somehow direct the preprocessor to "ignore the include path to open this header, but then use that same include path when reading that header". No compiler has that option. Your problem is over-constrained - you have code that does not work, and have so many constraints (imposed upon you or self-imposed?) that there is no way to get it working. – Peter
If none of the header files, as you now claim, include or depend on any other header file, then it's completely unclear what your problem is. Just include the right foo.hpp yourself. This question is completely incoherent. – Sam Varshavchik

2 Answers

0
votes

Assuming that you can give more elaborate relative paths:

If folder b is a subfolder of main.cpp's, you can just use

#include "<relative-path-to-folder-b>/foo.hpp"

If folder b isn't a subfolder and you can add another -I directive, then add another -I directive:

g++ main.cpp -o MyExe -I<path-to-folder-before-b> -I< path-to-folder-A > -I< path-to-folder-B >

and then add the include

#include "b/foo.hpp"
-1
votes

One (very brittle, hack-ish and possibly slow-to-compile) way of solving this relies on the manual include guards (#ifndef MY_HEADER etc.) that are presumably present in the headers in question:

  1. Gather all the header files that you want to use (excluding all the ones you don't want/need).

  2. Create a central include file that #includes all of these files (by as absolute of a path as you can, i.e. make sure this picks the correct foo.hpp gathered above, not one of the "original" ones).

  3. Tell your compiler to force-include this central include file. Realistically, you should just make this a precompiled header (or include it in yours).

  4. Due to force-including all these headers at the start of every translation unit, all the include guard defines are already set before you ever reach the point of the "wrong" headers being included. The compiler will still copy-paste them in there, but the include guards will prevent any code in them from being considered.