Re: [PATCH v2 3/4] python: set absolute path to libxl.h on _pyxl_types.c

[Roger Pau Monne <roger.pau@citrix.com>]

Ian Campbell wrote:
> On Fri, 2012-05-18 at 09:41 +0100, Roger Pau Monne wrote:
>> This fault was due to the way NetBSD pkgsrc builds Python, passing
>> OPT="-I/usr/include -I/usr/pkg/include ..." to the configure script,
>> which then gets saved to a Makefile that is parsed by distutils and
>> appended to the build of every extension. A bug report has already been
>> sent:
>>
>> http://mail-index.netbsd.org/pkgsrc-bugs/2012/05/17/msg047735.html
>>
>> Anyway, I don't think setting libxl.h path in genwrap.py is such a bad
>> idea, this file gets regenerated during every build, and we can make
>> sure we are always including the correct header (which should happen
>> automatically unless there are some underlying problems with Python,
>> like on NetBSD).
>
> I don't much like having absolute paths in includes. Imagine I moved my
> source tree, then very strange errors would occur. Also it should be
> unnecessary unless the underlying system has some very weird
> properties...

So at least the correct fix would be to replace

#include "libxl.h"

with

#include <libxl.h>

right?

> The right thing is to fix the underlying python problem, which it seems
> you have in hand.

Yes, I've send a PR, but the python port seems to have no specific 
maintainer, so I don't know how long it will take before someone picks 
it up...

> I considered suggesting using a relative include here but I expect it
> would get resolved relative to each of the -I options in turn
> (e.g. /usr/include/../libxl/libxl.h or whatever) which would be even
> worse IMHO.
>
> Ian.
>
>
>
>