On Tue, 2017-04-11 at 16:03 +0800, Li Zhou wrote:
>
> Remove building host related path from python2 and python3 packages.
>
> Signed-off-by: Li Zhou <li.z...@windriver.com>
> ---
> meta/recipes-devtools/python/python3_3.5.2.bb | 8 +++++++-
> meta/recipes-devtools/python/python_2.7.13.bb | 6 ++++++
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-devtools/python/python3_3.5.2.bb
> b/meta/recipes-devtools/python/python3_3.5.2.bb
> index 2ff7c9e..ca8dfe3 100644
> --- a/meta/recipes-devtools/python/python3_3.5.2.bb
> +++ b/meta/recipes-devtools/python/python3_3.5.2.bb
> @@ -185,9 +185,15 @@ py_package_preprocess () {
> install -m 0644 ${B}/Makefile.orig
> ${PKGD}/${libdir}/python${PYTHON_MAJMIN}/config-${PYTHON_MAJMIN}${PYTHON_ABI}/Makefile
> # Remove references to buildmachine paths in target Makefile and
> _sysconfigdata
> sed -i -e 's:--sysroot=${STAGING_DIR_TARGET}::g' -e
> s:'--with-libtool-sysroot=${STAGING_DIR_TARGET}'::g \
> + -e
> 's:${STAGING_DIR}/${MACHINE}${datadir}/pkgconfig:${datadir}/pkgconfig:g' \
> + -e 's:${STAGING_DIR_NATIVE}::g' \
> + -e 's:${STAGING_DIR_HOST}::g' \
> + -e 's:${WORKDIR}::g' \
> + -e 's:${TMPDIR}::g' \
> ${PKGD}/${libdir}/python${PYTHON_MAJMIN}/config/Makefile \
>
> ${PKGD}/${libdir}/python${PYTHON_MAJMIN}/config-${PYTHON_MAJMIN}${PYTHON_ABI}/Makefile
> \
> - ${PKGD}/${libdir}/python${PYTHON_MAJMIN}/_sysconfigdata.py
> + ${PKGD}/${libdir}/python${PYTHON_MAJMIN}/_sysconfigdata.py \
> + ${PKGD}/${bindir}/python${PYTHON_MAJMIN}${PYTHON_ABI}-config
> }
This breaks our builds since it regresses
$ oe-selftest -r sstatetests.SStateTests.test_sstate_sametune_samesigs
which is due to the use of MACHINE above. It also raises the question
about why we're fixing paths which do not exist in master?
This is the second patch in 24 hours from Wind River which is not
appropriate for master, not tested against it and actively breaks
things.
In case its not clear, the
path s:${STAGING_DIR}/${MACHINE}${datadir}/pkgconfig does not exist in
master after the RSS. You're therefore trying to get us to add complex
pointless broken code.
Yes, I'm not happy at all in case that isn't clear either as this is a
total waste of my time.
Richard
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
