[OpenWalnut-Dev] Includes

[Sebastian Eichelbaum]

Because we want to develop modules out-of-source. Absolute Paths are only used for libopenwalnut. Absolute paths are only used in modules and GUI.

With the current cmake install scripts, it is possible to install libopenwalnut and libopenwalnut-dev. Then you can use this (as you would use Qt for example) to develop your modules without the need of a complete OW source checkout.

Bye
Sebastian

On Tue, 23 Aug 2011, Alexander Wiebel wrote:

> 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
> _______________________________________________
> OpenWalnut-Dev mailing list
> OpenWalnut-Dev at lists.informatik.uni-leipzig.de
> http://lists.informatik.uni-leipzig.de/mailman/listinfo/openwalnut-dev
> 

-- 
Dipl.-Inf. Sebastian Eichelbaum
Universität Leipzig
Institut für Informatik
Abteilung Bild- und Signalverarbeitung
PF 100920
D-04009 Leipzig