adonthell-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Adonthell-devel] header include path conflicts


From: Kai Sterker
Subject: Re: [Adonthell-devel] header include path conflicts
Date: Mon, 16 Jul 2012 08:20:44 +0200

On Mon, Jul 16, 2012 at 6:31 AM, Chris Frey <address@hidden> wrote:

> I tried compiling Adonthell on a Debian squeeze machine this weekend, and
> ran into a problem with src/py-wrappers/adonthell/py_audio.i which includes
> "audio/sound.h".
>
> Unfortunately, this is the same name as under /usr/include/audio/sound.h,
> which is part of libaudio-dev, the network audio system. and python starts
> using libaudio headers in some parts and the build process uses adonthell's
> headers in others.
>
> This reveals a weak point in both adonthell's build system, and its library
> includes, in my opinion.
>
> Applications that build against adonthell, should include headers like this:
> #include <adonthell/audio/sound.h> instead of just <audio/sound.h>.
> And the headers should be installed under something like:
>
>         /usr/include/adonthell-1.1/adonthell/audio/sound.h
>
> so that applications can specify which version of adonthell they want to
> compile against, by setting -I/usr/include/adonthell-1.1 in their compiler
> flags.
>
> My idea is to add a symlink called adonthell, under build/ that links
> to src/.  The build/ directory is already in the -I include paths, so this
> makes including <adonthell/audio/sound.h> possible.  Then change all the
> applications, such as worldtest, to use <adonthell/...> and change the rest
> of the code only where needed.  Most of the time, when including headers
> in the same module, doing #include "sound.h" should be sufficient, but when
> including from another module, perhaps using the full 
> <adonthell/audio/sound.h>
> is a good idea.

There already had been a number of instances where header name
conflicts occured. So far they've been resolved by chosing different
names (area instead of map, for example). But this does not protect
against future conflicts and type names might become awkward too.

The changes you suggest would certainly eliminate this problem once
and for all. Although I believe that at least all headers need to have
their includes changed, as otherwise they may not be able to find them
once installed, when the include path only contains
/usr/include/adonthell-1.1/

Kai



reply via email to

[Prev in Thread] Current Thread [Next in Thread]