[OpenWalnut-Dev] Includes

[Sebastian Eichelbaum]

Well that sounds strange ... sorry. I meant that absolute paths are only in parts thats USE libopenwalnut.

On Wed, 24 Aug 2011, Sebastian Eichelbaum wrote:

> 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
> _______________________________________________
> 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