[oe] python-dir.bbclass question when using multiple versions of Python.

[Chris Larson]

On Thu, Aug 12, 2010 at 2:29 PM, Rodney Lott <rlott at evertz.com> wrote:

> Hi, there.
>
> I am looking at the latest revision from org.openembedded.dev:
>
> =========================================
> rlott at rlott-desktop:~/git/oe/oe-meta/classes$ git log -1
> commit ad112ee1ce53dfaf3fa2d7a10a79f724c8dd6335
> Author: Martin Jansa <Martin.Jansa at gmail.com>
> Date:   Thu Aug 12 22:28:35 2010 +0200
>
>    task-shr-feed: add supertux-qvga wesnoth
>
>    Signed-off-by: Martin Jansa <Martin.Jansa at gmail.com>
> rlott at rlott-desktop:~/git/oe/oe-meta/classes$ git br
>  master
> * org.openembedded.dev
>  org.openembedded.stable
> ==========================================
>
> I am looking at the classes/python-dir.bbclass function:
>
> ==========================================
> def python_dir(d):
>    import os, bb
>    staging_incdir = bb.data.getVar( "STAGING_INCDIR", d, 1 )
>    for majmin in "2.6 2.5 2.4 2.3".split():
>        if os.path.exists( "%s/python%s" % ( staging_incdir, majmin ) ):
> return "python%s" % majmin
>    if not "python-native" in bb.data.getVar( "DEPENDS", d, 1 ).split():
>        raise Exception("No Python in STAGING_INCDIR. Forgot to build
> python-native?")
>    return "INVALID"
>
> PYTHON_DIR = "${@python_dir(d)}"
> PYTHON_SITEPACKAGES_DIR = "${libdir}/${PYTHON_DIR}/site-packages"
> ==========================================
>
> Now, if I am reading this correctly, it would seem that the logic of this
> function is as follows, "Look for python directories in STAGING_INCDIR,
> starting from 2.6 downward, and use the first one I find."
>
> This works if one is only using one version of Python.  Let's say one is
> using Python 2.5 and Python 2.6 (i.e. for two different applications) and I
> am in the process of building something that I need to work with Python 2.6,
> it will set PYTHON_DIR to point to /usr/lib/python2.6/site-packages, which
> isn't what I want.
>
> So, my question is this:  Is it OE's assumption that one is only to use a
> single version of Python within one build (i.e. one tmp directory), or
> should it work with multiple Pythons per temp directory?  If it is the
> later, then it would seem to me that using STAGING_INCDIR to determine the
> Python version isn't a good idea and that the Python version one is using
> should be derived (somehow) from the PREFERRED_VERSION_python and
> PREFERRED_VERSION_python-native settings


Building multiple versions of *anything* in a single build is prone to
failure and problems.  Headers will step on one another's toes in staging
depending on the build order, etc.  Python is no exception.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics