Re: [OE-core] [PATCH v2 2/5] toolchain-scripts.bbclass: Support target-specific environment setup scripts

[Harish Sadineni <Harish.Sadineni@windriver.com>]

On 9/18/2025 9:29 PM, Ross Burton wrote:
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
> On 15 Sep 2025, at 11:27, Sadineni, Harish via lists.openembedded.org <Harish.Sadineni=windriver.com@lists.openembedded.org> wrote:
>> From: Harish Sadineni <Harish.Sadineni@windriver.com>
>>
>> YOCTO [#15061]
>> Extending the SDK environment setup logic to also source scripts from a
>> target-specific directory `${TARGET_SYS}_environment-setup.d`, if it exists.
>> +if [ -d "\$OECORE_NATIVE_SYSROOT/${TARGET_SYS}_environment-setup.d" ]; then
> We already have a target-specific directory already: populated by the target recipes.
>
> The SDKs are constructed in two parts:
>
> - The target recipes (eg libxml2) are used to build the target sysroot. In this case, the same package that provides /usr/lib/libxml2.so <http://libxml2.so/> on the target will be used in the target sysroot to link against.
>
> - The nativesdk recipes (eg nativesdk-libxml2) are used to build the native sysroot (thus the name, native for the SDK).  So in this case, nativesdk-libxml2 will provide the xmllint binary in the SDK.
>
> There should be _no_ connection between the target MACHINE and the nativesdk recipes, just like there is no connection between target and native. As the native sysroot is populated from nativesdk recipes, they shouldn’t be able to know what the final target actually is.
>
> Where you have crossover there currently needs to be a little magic, for example the nativesdk-cmake recipe has an environment.d script that takes the target configuration from the environment variables and generates CMake configuration.
Hi Ross,

Thanks for clarification, we referred how nativesdk-cmake recipe has 
handling environment.d script(cmake.sh) it is Copying necessary files 
into the SDK without expanding any values at build time but with rust.sh 
and cargo.sh it will need to expand values at build time so we can't 
adopt that.

And from your comments, we understand that target-specific components 
should reside within the target sysroot, and only nativesdk components 
should be placed in the native sysroot.

Based on this, we're now moving our ${TARGET_SYS}_environment-setup.d 
directory to the target sysroot from native sysroot.

And now we observe the following target sysroots under sysroots 
directory when using multilib:
x86_64-pokysdk-linux
x86-64-v3-poky-linux
x86-pokymllib32-linux

Is this what you are referring to, is our understanding correct with 
this change?

Thanks,
Harish

>
> Ross