[OE-core] [PATCH] python-setuptools.inc: avoid using += with an over-ride
Richard Purdie
richard.purdie at linuxfoundation.org
Fri Jul 6 09:11:58 UTC 2018
On Thu, 2018-07-05 at 17:57 -0700, Andre McCurdy wrote:
> On Thu, Jul 5, 2018 at 5:07 PM, Burton, Ross <ross.burton at intel.com>
> wrote:
> > On 6 July 2018 at 00:39, Andre McCurdy <armccurdy at gmail.com> wrote:
> > > On Wed, Jul 4, 2018 at 5:53 AM, Burton, Ross <ross.burton at intel.c
> > > om> wrote:
> > > > On 4 July 2018 at 01:55, Andre McCurdy <armccurdy at gmail.com>
> > > > wrote:
> > > > > DEPENDS += "${PYTHON_PN}"
> > > > > -DEPENDS_class-native += "${PYTHON_PN}-native"
> > > > > -DEPENDS_class-nativesdk += "nativesdk-${PYTHON_PN}"
> > > > > +DEPENDS_class-native = "${PYTHON_PN}-native"
> > > > > +DEPENDS_class-nativesdk = "nativesdk-${PYTHON_PN}"
> > > >
> > > > Whilst there's nothing wrong with this patch, as the
> > > > BBCLASSEXTEND
> > > > handles DEPENDS-munging isn't this a better fix:
> > > >
> > > > DEPENDS += "${PYTHON_PN}"
> > > > -DEPENDS_class-native += "${PYTHON_PN}-native"
> > > > -DEPENDS_class-nativesdk += "nativesdk-${PYTHON_PN}"
> > >
> > > Removing the over-rides completely results in both the native and
> > > nativesdk variants gaining a new dependency on
> > > python-distribute-native (courtesy of setuptools.bbclass).
> >
> > setuptools.bbclass:DEPENDS += "python-distribute-native"
> >
> > If python-distribute-native is a build dependency for target then
> > its a dependency for native and nativesdk too, right?
>
> DEPENDS has been over-ridden for native and nativesdk for some time,
> so either the dependency gets provided indirectly or it's not
> required at all?
I'd suspect indirectly but hard to tell :/.
> > Considering python-distribute is just an alias for python-
> > setuptools
> > (its a RPROVIDES in the recipe, and the pip entry is just a
> > dependnecy) I guess the setuptools class should follow setuptools3
> > and
> > depend on python-setuptools-native instead of
> > python-distribute-native.
> >
> > Context is this from 2015:
> >
> > commit c4553e07cdbec5c29a74a43e0c5fdb2bb5583f7a
> > Author: Alejandro Hernandez <alejandro.hernandez at linux.intel.com>
> > Date: Thu May 14 16:49:56 2015 +0000
> >
> > python3-distribute: Upgrade to python3-setuptools 15.2
> >
> > python3-distribute was merged back to python3-setuptools in
> > 2013,
> > and it is no longer being maintained, this upgrade also
> > provides
> > functionality that will be needed for python3-pip.
> >
> > The same needs to be applied to the py2 classes, as both Py2 and
> > Py3
> > use the same version of setuptools.
>
> That all sounds plausible, but starts to unravel into a bigger set of
> potential cleanups. For example, digging a little more uncovers this
> from distutils-base.bbclass:
>
> DEPENDS += "${@["${PYTHON_PN}-native ${PYTHON_PN}",
> ""][(d.getVar('PACKAGES') == '')]}"
> RDEPENDS_${PN} += "${@['', '${PYTHON_PN}-core']['${CLASSOVERRIDE}'
> == 'class-target']}"
>
> The first line adding to DEPENDS for target and nativesdk (but not
> native) and the second line adding to RDEPENDS for target only.
> Should this be re-written to make use of over-rides?
I suspect class- overrides did not exist when that code was written.
Rewriting it using them would be a good cleanup.
> And looking at nativesdk builds in general, why does
> DISTRO_FEATURES_NATIVE contain ipv6 and xattr but
> DISTRO_FEATURES_NATIVESDK does not? I couldn't find any comments to
> explain that.
I suspect nativesdk should have those and its just a oversight.
Unfortunately we have a number of little details like this, I do take a
pass at some things when I have time but clearly there are things which
can be improved.
FWIW I tend to look at them from a risk perspective too and how well we
can know whether the cleanup will or won't risk breakage before
deciding where to make changes.
Cheers,
Richard
More information about the Openembedded-core
mailing list