On Thu, Jul 5, 2018 at 5:07 PM, Burton, Ross <ross.bur...@intel.com> wrote:
> On 6 July 2018 at 00:39, Andre McCurdy <armccu...@gmail.com> wrote:
>> On Wed, Jul 4, 2018 at 5:53 AM, Burton, Ross <ross.bur...@intel.com> wrote:
>>> On 4 July 2018 at 01:55, Andre McCurdy <armccu...@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?
> 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.hernan...@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?
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.
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
