Hi Sebastian,
You question is not a GCC specific question, it's more of a Lakos'
Large-Scale C++ Software Design question, and is off-topic for this forum.
Not that I'm chastising you, but you may be a better caliber of answer on a
more appropriate forum.
> My question is: What is the correct/preferred way to #include "header2.h" in
file1.c?
There is no "correct/preferred" way. There are many different conventions.
So it depends on the convention of the team for the particular project.
For my own projects, *MY* preferred way is this structure for my Foo, Bar
and Quux projects:
common/
project/
root/
Foo/
FooWidget.h
Makefile
src/
FooWidget.cpp
FooWidgetImpl.h
Bar/
BarGizmo.h
Makefile
src/
BarGizmo.cpp
BarGizmoImpl.h
Quux/
QuuxGadget.h
Makefile
src/
QuuxGadget.cpp
QuuxGadgetImpl.h
In the source, there would be #include blocks such as...
QuuxGadget.cpp might have something like:
#include "Quux/QuuxGadget.h" // Self
#include "QuuxGadgetImpl.h" // Implementation-via-inheritance pattern
#include "Bar/BarGizmo.h"
#include <iostream>
#include <cassert> // Always last; not idempotent.
BarGizmo.cpp might have:
#include "Bar/BarGizmo.h" // Self
#include "BarGizmoImpl.h" // PImpl pattern
#include "Foo/FooWidget.h"
#include <fstream>
#include <sstream>
#include <cassert> // Always last; not idempotent.
And FooWidget.cpp:
#include "Foo/FooWidget.h" // Self
#include "FooWidgetImpl.h" // Implementation of Opaque types
#include <string>
#include <cassert> // Always last; not idempotent.
All sub-projects are peers to one another, based off of a common shared
project root for the public headers, which specify the public APIs. And all
the private stuff (.cpp and .h) is in the src subdirectory.
> I could use #include "../header2.h" in file1.c.
My own hard rule is NEVER use backtracking traversal in a #include
specification.
Because of the semantics of symbolic links, they may not do what you think
they'll do. Or if you are symbolic link savvy, they may not do what other
people think they'll do. And they may not be supported on all platforms, if
you are concerned about portability.
And although you can use backtracking in the -I.. specification in the
sub-project's Makefile, I prefer to use an absolute and fully qualified path
to the common shared project root.
BTW, regarding Makefile, please read "Recursive Make Considered Harmful"
<http://members.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html>. You
may want to consider using "makefile fragments" instead of recursive make --
which would be yet-another-disciplined-convention.
HTH,
--Eljay
