[poky] [PATCH 1/5] staging: Use relative path in sysroot-destdir for target recipes

Xu, Dongxiao dongxiao.xu at intel.com
Mon Jan 17 17:33:40 PST 2011


Xu, Dongxiao wrote:
> Hi Richard,
> 
> Richard Purdie wrote:
>> 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?
> 
> 
> ${base_prefix} has some kinds of values considerring different recipe
> type. (we do not discuss cross and crosssdk) 
> 
> Normal target recipe: base_prefix = ""
> Native recipes: base_prefix = "${STAGING_DIR_NATIVE}"
> Nativesdk recipes: base_prefix = "${SDKPATHNATIVE}"
> Cross-canadian recipes: base_prefix = "${SDKPATHNATIVE}"
> 
> For target recipes, the input and output dirs should be:
> Input: ${SYSROOT_DESTDIR}
> Output: ${STAGING_DIR_HOST}
> 
> For native recipes, the input and output dirs should be:
> Input: ${SYSROOT_DESTDIR}/${STAGING_DIR_NATIVE}
> Output: "${STAGING_DIR_NATIVE}"
> 
> For nativesdk recipes, the input and output dirs should be:
> Input: ${SYSROOT_DESTDIR}/${SDKPATHNATIVE}
> Output: "${STAGING_DIR_HOST}/${SDKPATHNATIVE}
> 
> For cross-canadian recipes, the input and output dirs should be:
> Input: ${SYSROOT_DESTDIR}/${SDKPATHNATIVE}
> Output: "${STAGING_DIR_HOST}/${SDKPATHNATIVE}
> 
> It is workable if change to your latter option.
> do_populate_sysroot[sstate-inputdirs] = "${SYSROOT_DESTDIR}"
> do_populate_sysroot[sstate-outputdirs] = "${STAGING_DIR_HOST}"
> 
> In this case we need to specially handle native cases.

Native case could also be handled by that pair, since for native, STAGING_DIR_HOST is "".

Thanks much for your hint, this simplifies the patch.

-- Dongxiao

> 
>> 
>> 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.
> 
> OK, I will change accordingly.
> 
> Thanks,
> Dongxiao
> 
>> 
>> Cheers,
>> 
>> Richard




More information about the poky mailing list