[OpenWalnut-Dev] Includes

[Mathias Goldau]

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