On Thu, 2018-07-05 at 17:57 -0700, Andre McCurdy wrote: > On Thu, Jul 5, 2018 at 5:07 PM, Burton, Ross <[email protected]> > wrote: > > On 6 July 2018 at 00:39, Andre McCurdy <[email protected]> wrote: > > > On Wed, Jul 4, 2018 at 5:53 AM, Burton, Ross <[email protected] > > > om> wrote: > > > > On 4 July 2018 at 01:55, Andre McCurdy <[email protected]> > > > > 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 <[email protected]> > > 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 -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
