[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openembedded-core
Subject:    [OE-core] [PATCH]] python: Unbreak Python third-party extensions
From:       michael.lippautz () gmail ! com (Michael Lippautz)
Date:       2011-04-29 11:48:10
Message-ID: BANLkTik1anmE4n7fKMp4uV9ZSLK1Gx_C0g () mail ! gmail ! com
[Download RAW message or body]

2011/4/29 Koen Kooi <koen at dominion.thruhere.net>:
> 
> Op 29 apr 2011, om 12:44 heeft Michael Lippautz het volgende geschreven:
> 
> > This fixes compilation/linking of Python 3rd party extensions.
> > 
> > ${STAGING_LIBDIR}/python<pyver>/config/Makefile needs the correct
> > INCDIR and LIBDIR settings to be used in cross compilation for the
> > target. 3rd party module use distutils.sysconfig which uses this
> > Makefile to create compiler/linker flags.
> > 
> > Workflow:
> > 1) compile needs the staged/sysroot Makefile since it is needed
> > ? for compilation/linking
> > 2) install needs the unmodified Makefile to install files (i.e.
> > ? headers) into the right directores. (otherwise they would be
> > ? installed in ${D}/${STAGING_...}
> > 3) staging needs modified Makefile again
> > 4) packaging needs unmodified to make compilation on the target
> > ? possible
> 
> Does any of the sysroot leak into the 3rd party extensions after this patch? Apart \
> from that question, the patch looks good to me, although I needed a cup of coffee \
> to work out the flow.

Nothing leaks into the 3rd party extensions as far as I know. The
Makefile is used by distutils (i.e. distutils.sysconfig) to determine
the compiler settings.

In the case of a 3rd partyextension the flow is as follows:
* distutils.bbclass uses python-native + distutils-native to generate
the package
* distutils-native looks up the compiler settings via
distutils.sysconfig (-native) in
${STAGING_LIBDIR}/python<pyver>/config/Makefile
  (it is thus important that STAGING_LIBDIR is set by distutils.bbclass)
* 3rd party extension is compiled using the settings from this Makefile

The compilation on the target should still be possible (although I
didn't test it), because the target's Makefile is untouched.

The actual problem was that the targets Makefile did get staged and
the compiler and linker have been invoked with the targets libs, for
instance -L/usr/lib.

> regards,
> 
> Koen

(I needed more than one coffee to figure out this flow)

-Michael


[prev in list] [next in list] [prev in thread] [next in thread]