[OpenWalnut-Dev] Includes

[Alexander Wiebel]

Hi,
why did the paths change to absolute from relative?
Example:

#include "core/common/WAssert.h"
instead of
#include "../../core/common/WAssert.h"
from a module's directory

Please consider the discussion we had for FAnToM (see below).

Thanks for clarifying this for me.

Cheers
Alex


-------- Original-Nachricht (anonymisisert) --------
Betreff: Re: [FAnToM] Includes of FAnToM
Datum: Thu, 09 Jul 2009 15:01:54 +0200
Von: CH
Organisation: University of Leipzig, Germany
An: XT
CC: List

Hi,

XT schrieb:
> Hi,
>
> May we ask why? This new convention sounds overly cumbersome. I
guess
> I am just lacking a clear understanding of the problems that led to
> that decision.
>
> Thanks,
> XT

Overall this should increase the building of fanton if few things
have changed, and removes an highly unlikely strange effect, if not
security hole.

In detail, the answer is simply because

(a) #include "common/src/FString.hh"

it is bad for the build environment. It should be either

(b) #include "../../common/src/FString.hh"

or

(c) #include <common/src/FString.hh>

(a) is correct code, because the §16.2 of the C++ standart (current
working draft of c++-0x) states that in the case of (a) a compiler
should look for the included file *relative* to the including file
and if that search fails it should treat it as (c). But the search
for (a) always fails and forces the compiler to traverse the
standard include directories. Also, (c) can not avoid that a system
installed <common/src/FString.hh> is used rather than the one that
is actually meant (although highly unlikly), and neither does (a) if
the compiler is forced to fall back to (c).

Because the search for (a) always fails it forces the compiler to do
many unneccessary stats. Using (c) rather than (a) removes only one
of them. I suggested to use (b) rather than (c) to minimize the
number of search directories for includes and to improve on the
build speed. Furthermore, (a) confuses the automatic generation of
dependencies. I have observed that some files occur up to three
times in the dependencies (for each object file), always using
different paths. This can slow down the build environment,
especially on NFS, because to determine whether a target has to be
rebuilt, these file have to be stat as many times as they occur in
the dependency lists.

I agree that (b) looks bad, but it looks bad for a reason. It shows
a poor modularization of FAnToM. It will probably look nicer if the
whole directory restructuring is finished. But that won't remedy the
original problem.

Best regards,
CH