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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2012-05-17 at 15:02 +0100, Roger Pau Monne wrote:
> Ian Campbell wrote:
> > On Thu, 2012-05-17 at 13:16 +0100, Roger Pau Monne wrote:
> >> genwrap.py generates _pyxl_types.c, which includes libxl.h, but if
> >> libxl.h is already present in the include search path, the old one was
> >> included instead of the new one, giving compilation errors. Since
> >> _pyxl_types.c is generated at compilation time, we can safely set
> >> the path to libxl.h include.
> >>
> >> I've only experienced this problem when compiling Xen on NetBSD with
> >> old header files in the include path, Linux seems to not have this
> >> problem.
> >
> > Should this be include<>  and not "", since libxl.h isn't in the current
> > dir in this case?
> >
> > Is the right fix to make sure that the in-tree -I lines come first?
> > Ian.
> 
> Actually I'm not sure if it's possible to make sure the in-tree -I lines 
> come first, because the gcc options are automatically generated by 
> python build tools (distutils & friends...), so we cannot touch much of 
> this (I've looked at distutils.core options, and it seems to be no way 
> of setting an order on compiler options, but I'm no expert on python C 
> extensions building), so unless we craft our own makefile to build this 
> python stuff I think we are stuck with something like this.

Surely distutils puts user supplied options first before system options?
My /usr/lib/python2.5/distutils/command/build_ext.py says:
 
       # Put the Python "system" include dir at the end, so that
        # any local include dirs take precedence.
        self.include_dirs.append(py_include)
        if plat_py_include != py_include:
            self.include_dirs.append(plat_py_include)

So it seems like this is the intention.

Are you sure this isn't just a bug in your version of distutils or
something like that?

My python xl builds end up as:
        building 'xl' extension
        gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
        -Wstrict-prototypes -O1 -fno-omit-frame-pointer -m32 -march=i686
        -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes
        -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .build.d
        -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
        -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls
        -mno-tls-direct-seg-refs -fPIC -I../../tools/include
        -I../../tools/libxl -I../../tools/libxc -Ixen/lowlevel/xl
        -I/usr/include/python2.6 -c xen/lowlevel/xl/xl.c -o
        build/temp.linux-i686-2.6/xen/lowlevel/xl/xl.o
        -fno-strict-aliasing -Werror

Which has our local -I options before all the others -- which is
sensible. What do you see with your system?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel