-2

I can't make gcc compiler recognize complex paths in "includes".

Here's my toy "main.cpp" file (note the sub-directory in the include statement):

#include "sub/testlib.h"

int main()
{
    testlib(6);
    return 0;
}

Here's the path to the file "testlib.h" from the folder "main.cpp" lives in: ../lib/sub/testlib.h.

I'm specifying the include directory while compiling:

gcc -c -iquote../lib main.cpp

And the compiler yells at me:

main.cpp:1:10: fatal error: sub/testlib.h: No such file or directory
    1 | #include "sub/testlib.h"
      |          ^~~~~~~~~~~~~~~
compilation terminated.

Of course I can make it compile by removing sub-directory from the path. But this is just an experiment I make after having failed to compile a real-world project. I can't freely change the files there.

How do I force gcc to treat sub-directories well in the includes? Is there a flag or some option that I'm missing here?

Leonid Zakirov
  • 21
  • 1
  • 7

1 Answers1

1

How do I force gcc to treat sub-directories well in the includes? Is there a flag or some option that I'm missing here?

Read the documentation of GCC, in particular the Invoking GCC chapter, the section on preprocessor options (e.g. -I include-dir or -H or -M, etc...), the documentation of the preprocessor. Try also g++ --help ; the -I include-directory flag can be repeated a lot of times and is probably what you need. Of course, order of arguments to the g++ program matters a lot. You probably want to use g++ not gcc when compiling or linking C++ programs.

Read also some documentation of C++ (maybe even the n3337 "draft" standard). Be aware of translation units, and of the role of the linker.

In practice, you want to drive GCC compilation using some build automation tool, such as GNU make or ninja or many others.

If you use GNU make, read its documentation then try make -p which shows the many built-in rules known to that software. Be aware of the many functions of make.

If you use ninja, read its documentation, you probably want to generate the build.ninja script it is using. You could generate it using a Python script or a Guile one (or your own C++ program, etc...).

Be aware that of course g++ will invoke some GNU binutils utilities (e.g. the assembler as or the linker ld).

Practically speaking, invoke g++ as g++ -Wall -Wextra -g to get warnings and debug information (of course with additional -I include-directory flags). Then use the gdb debugger. Once your program has few bugs, add optimization flags such as -O2

See also Clang, its static analyzer, Frama-C, and CompCert and, at end of 2020, Bismon.

Consider in some cases to generate some #include-d C++ code (e.g. with SWIG or ANTLR or Qt or your own script) or to extend GCC with your plugins.

Be of course aware of the Joel Test.

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
  • Thank you! I certainly will spend more time reading the docs. I'm still too inexperienced, making typos and believing it has something to do with the compiler itself. – Leonid Zakirov Apr 23 '20 at 10:30
  • 1
    As a rule of thumb, trust the compiler much more than yourself. The GCC project has very strong code review practices. – Basile Starynkevitch Apr 23 '20 at 10:32
  • That's a lot of links. But your answer doesn't really make much sense to me as your answer isn't self contained. It looks like you've basically just said GTFO&RTFM. – Peilonrayz Apr 23 '20 at 10:47
  • @Peilonrayz Yes indeed. I am a big advocate of reading documentation; I strongly believe people should spend more time in reading it. Writing any kind of documentation is a lot of efforts. – Basile Starynkevitch Apr 23 '20 at 10:48
  • @BasileStarynkevitch I read and have written enough documentation to understand that. However the presence of documentation doesn't justify writing incoherent nonsense. – Peilonrayz Apr 23 '20 at 13:20