2

Given the following directory structure:

enter image description here

Notice how there are two files named System-Libraries.hpp

The way I include either currently is:

#include "System-Libraries.hpp"

So clearly there is an ambiguity here. This project compiles and runs, so the system seems to be currently finding the correct header, but I don't expect this to be because of defined behaviour I think I am just getting lucky.

How do CMake, Make and g++ determine which of the 2 files will be used for compilation for a given cpp?

Note I am not asking how to fix it, fixing it involves either changing the header names so that they are different or including the relative path on inclusion, this is not what I am worried about. I want to know why neither CMake nor g++ complain about the two files being named the same and being included in the same final executable.

Makogan
  • 8,208
  • 7
  • 44
  • 112
  • A duplicate from: https://stackoverflow.com/questions/21593/what-is-the-difference-between-include-filename-and-include-filename ? – Amadeus Apr 16 '18 at 02:46
  • @Amadeus how is this a duplicate? my question and the linked one have nothing to do with each other. i am not asking about the difference between "" and <> when including a header. i am asking what heppens when you have two different headers with the same name – Makogan Apr 16 '18 at 02:49
  • Have you read this part: _For #include "filename" the preprocessor searches first in **the same directory** as the file containing the directive_ ? That is your answer. Compiler looks at the directory where your source file is – Amadeus Apr 16 '18 at 02:51
  • This one might be a closer dup: [Library include paths with same header name](https://stackoverflow.com/q/5168242/608639). I'm not sure CMake has a material effect on the issue. It is a issue that resides in the compiler and preprocessor; not the tool driving the compilation process. – jww Apr 16 '18 at 02:52
  • I'm guessing that it will simply include the first occurrence of that filename that it finds. I had this problem in a project before and it appeared when I changed the order of my `include_directories` in my `CMakeList.txt`. – super Apr 16 '18 at 02:54
  • @Amadeus Yes I read that part. Notice how neither of the 2 library headers are on the same directory as the lowest level directory files. So that part does not apply for those files – Makogan Apr 16 '18 at 03:18

1 Answers1

2

The preprocessor searches for include files in this order:

Quoted form:

  • In the same directory as the file that contains the #include statement.
  • In the directories of the currently opened include files, in the reverse order in which they were opened. The search begins in the directory of the parent include file and continues upward through the directories of any grandparent include files.
  • Along the path that's specified by each /I compiler option.
  • Along the paths that are specified by the INCLUDE environment variable.

Angle-bracket form :

  • Along the path that's specified by each /I compiler option.
  • When compiling occurs on the command line, along the paths that are specified by the INCLUDE environment variable.
Jarod42
  • 203,559
  • 14
  • 181
  • 302
moinmaroofi
  • 359
  • 1
  • 12
  • It is a little more complicated than that as pedantically, it relies on implementation. – Jarod42 Apr 16 '18 at 11:50
  • 1
    These details are compiler-specific. You **really must** say which compiler you're talking about. According to the language definition, `#include <...>` "searches a sequence of implementation-defined places for a header" (note that it says "header", not "file"; a header does not have to be a file), and `#include "..."` searches for a "source file ... in an implementation-defined manner", and if that search fails, the directive is reprocessed as if it has used `<...>` rather than `"..."`. So you always have to fall back on implementation details to know what's going on. – Pete Becker Apr 16 '18 at 13:08