[OpenWalnut-Dev] Includes

[Sebastian Eichelbaum]

Hast schon recht. Aber zur zeit ist das so nicht möglich, da wir kein Verzeichnis "ow" haben. Ich kümmere mich schon drum. Wenn es soweit ist.

Gruß

On Wed, 24 Aug 2011, Mathias Goldau wrote:

> Um mal im TOFU Stil zu bleiben:
> 
> Wir sollten die absoluten Pfade dann aber in spitze Klammern schreiben und
> auch openwalnut als path element einfügen ala:
> 
> #include <ow/common/WAssert.h>
> 
> anstelle von:
> 
> #include "common/WAssert.h"
> 
> Das macht die benutzung von OpenWalnut als lib viel deutlicher. Andere
> Projekte wie boost, osg und qt machen es ja auch so!
> 
> Mathias
> 
> Am 24.08.2011 13:19, Sebastian Eichelbaum wrote:
> > 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
> >>
> > 
> 
> 
> -- 
> Institut für Informatik
> Universität Leipzig
> Johannisgasse 26, 04103 Leipzig
> Phone: +493419732283
> _______________________________________________
> 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