From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Dongxiao Xu <dongxiao.xu@intel.com>
Cc: poky@yoctoproject.org
Subject: Re: [PATCH 1/5] staging: Use relative path in sysroot-destdir for target recipes
Date: Mon, 17 Jan 2011 22:42:13 +0000 [thread overview]
Message-ID: <1295304133.14388.15857.camel@rex> (raw)
In-Reply-To: <a84ff52c94c4299e9c6093539ba25bc5df7769e6.1295042140.git.dongxiao.xu@intel.com>
Hi Dongxaio,
I agree with this patch as you know and I want to merge it but I'm not
entirely sure its 100% right yet.
On Sat, 2011-01-15 at 06:14 +0800, Dongxiao Xu wrote:
> diff --git a/meta/classes/staging.bbclass b/meta/classes/staging.bbclass
> index 8432565..4d2991b 100644
> --- a/meta/classes/staging.bbclass
> +++ b/meta/classes/staging.bbclass
> @@ -45,25 +45,25 @@ sysroot_stage_dirs() {
> from="$1"
> to="$2"
>
> - sysroot_stage_dir $from${includedir} $to${STAGING_INCDIR}
> + sysroot_stage_dir $from${includedir} $to${includedir}
> if [ "${BUILD_SYS}" = "${HOST_SYS}" ]; then
> - sysroot_stage_dir $from${bindir} $to${STAGING_DIR_HOST}${bindir}
> - sysroot_stage_dir $from${sbindir} $to${STAGING_DIR_HOST}${sbindir}
> - sysroot_stage_dir $from${base_bindir} $to${STAGING_DIR_HOST}${base_bindir}
> - sysroot_stage_dir $from${base_sbindir} $to${STAGING_DIR_HOST}${base_sbindir}
> - sysroot_stage_dir $from${libexecdir} $to${STAGING_DIR_HOST}${libexecdir}
> - sysroot_stage_dir $from${sysconfdir} $to${STAGING_DIR_HOST}${sysconfdir}
> - sysroot_stage_dir $from${localstatedir} $to${STAGING_DIR_HOST}${localstatedir}
> + sysroot_stage_dir $from${bindir} $to${bindir}
> + sysroot_stage_dir $from${sbindir} $to${sbindir}
> + sysroot_stage_dir $from${base_bindir} $to${base_bindir}
> + sysroot_stage_dir $from${base_sbindir} $to${base_sbindir}
> + sysroot_stage_dir $from${libexecdir} $to${libexecdir}
> + sysroot_stage_dir $from${sysconfdir} $to${sysconfdir}
> + sysroot_stage_dir $from${localstatedir} $to${localstatedir}
> fi
> if [ -d $from${libdir} ]
> then
> - sysroot_stage_libdir $from/${libdir} $to${STAGING_LIBDIR}
> + sysroot_stage_libdir $from/${libdir} $to${libdir}
> fi
> if [ -d $from${base_libdir} ]
> then
> - sysroot_stage_libdir $from${base_libdir} $to${STAGING_DIR_HOST}${base_libdir}
> + sysroot_stage_libdir $from${base_libdir} $to${base_libdir}
> fi
> - sysroot_stage_dir $from${datadir} $to${STAGING_DATADIR}
> + sysroot_stage_dir $from${datadir} $to${datadir}
> }
>
> sysroot_stage_all() {
> @@ -76,6 +76,7 @@ do_populate_sysroot[dirs] = "${STAGING_DIR_TARGET}/${bindir} ${STAGING_DIR_TARGE
> ${STAGING_INCDIR_NATIVE} \
> ${STAGING_DATADIR} \
> ${SYSROOT_DESTDIR}${STAGING_DIR_TARGET} \
> + ${SYSROOT_DESTDIR}${base_prefix} \
> ${S} ${B}"
>
> # Could be compile but populate_sysroot and do_install shouldn't run at the same time
> @@ -103,8 +104,8 @@ python do_populate_sysroot () {
>
> SSTATETASKS += "do_populate_sysroot"
> do_populate_sysroot[sstate-name] = "populate-sysroot"
> -do_populate_sysroot[sstate-inputdirs] = "${SYSROOT_DESTDIR}/${STAGING_DIR}"
> -do_populate_sysroot[sstate-outputdirs] = "${TMPDIR}/sysroots"
> +do_populate_sysroot[sstate-inputdirs] = "${SYSROOT_DESTDIR}/${base_prefix}"
> +do_populate_sysroot[sstate-outputdirs] = "${STAGING_DIR_HOST}/"
The reason why is I'm still not 100% comfortable with the two lines
above. They look unbalanced and should really be paired to match such
that they'd either be:
do_populate_sysroot[sstate-inputdirs] = "${SYSROOT_DESTDIR}/${base_prefix}"
do_populate_sysroot[sstate-outputdirs] = "${STAGING_DIR_HOST}/${base_prefix}"
or
do_populate_sysroot[sstate-inputdirs] = "${SYSROOT_DESTDIR}"
do_populate_sysroot[sstate-outputdirs] = "${STAGING_DIR_HOST}"
but just looking at code I'm having trouble working out whether either,
both or neither of these would work and in which cases.
The cross/crosssdk recipes are a mess as they install into two different
sysroots. Dexuan is working on some changes to improve that so I'm least
worried about those two classes and the patch I just merged for libgcc
is going to help. I'm therefore aiming for this to work for the
target/native/nativesdk/cross-canadian cases and the cross/crosssdk one
is secondary and can be messy for now if needed.
I feel most comfortable aiming for the latter of my two options above,
does that work assuming we hack cross/crosssdk to do whatever is needed
to make them work with it? Can the others then remain unaltered?
The other minor thing I'm thinking about is adding a definition of:
bindir_crossscripts = "${bindir}/crossscripts"
to bitbake.conf (near the top next to bindir_cross) and using that in
the sysroot functions.
Cheers,
Richard
next prev parent reply other threads:[~2011-01-17 22:42 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-14 22:14 [PATCH 0/5][RFC v4] Machine specific sysroot implementation Dongxiao Xu
2011-01-14 22:14 ` [PATCH 1/5] staging: Use relative path in sysroot-destdir for target recipes Dongxiao Xu
2011-01-17 22:42 ` Richard Purdie [this message]
2011-01-18 0:45 ` Xu, Dongxiao
2011-01-18 1:33 ` Xu, Dongxiao
2011-01-14 22:14 ` [PATCH 2/5] staging: relocate *.la paths in destination dirs Dongxiao Xu
2011-01-17 22:10 ` Richard Purdie
2011-01-14 22:14 ` [PATCH 3/5] bitbake: Introduce stamp-extra-info into build stamp file Dongxiao Xu
2011-01-18 12:53 ` Richard Purdie
2011-01-14 22:14 ` [PATCH 4/5] bitbake: machine specific sysroots implementation Dongxiao Xu
2011-01-14 22:14 ` [PATCH 5/5] emenlow: Change PACKAGE_EXTRA_ARCHS and BASE_PACKAGE_ARCH to core2 Dongxiao Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1295304133.14388.15857.camel@rex \
--to=richard.purdie@linuxfoundation.org \
--cc=dongxiao.xu@intel.com \
--cc=poky@yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.