| Message ID | 20250915102750.3298492-2-Harish.Sadineni@windriver.com |
|---|---|
| State | New |
| Headers | show |
| Series | [v2,1/5] Revert "rust: remove redundant cargo config file" | expand |
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. Ross
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
diff --git a/meta/classes-recipe/toolchain-scripts.bbclass b/meta/classes-recipe/toolchain-scripts.bbclass index 5d28df845b..c6f7faea81 100644 --- a/meta/classes-recipe/toolchain-scripts.bbclass +++ b/meta/classes-recipe/toolchain-scripts.bbclass @@ -163,14 +163,22 @@ toolchain_shared_env_script () { # Append environment subscripts if [ -d "\$OECORE_TARGET_SYSROOT/environment-setup.d" ]; then for envfile in \$OECORE_TARGET_SYSROOT/environment-setup.d/*.sh; do + echo "Sourcing target env file: \$(basename "\$envfile")" . \$envfile done fi if [ -d "\$OECORE_NATIVE_SYSROOT/environment-setup.d" ]; then for envfile in \$OECORE_NATIVE_SYSROOT/environment-setup.d/*.sh; do + echo "Sourcing target env file: \$(basename "\$envfile")" . \$envfile done fi +if [ -d "\$OECORE_NATIVE_SYSROOT/${TARGET_SYS}_environment-setup.d" ]; then + for envfile in \$OECORE_NATIVE_SYSROOT/${TARGET_SYS}_environment-setup.d/*.sh; do + echo "Sourcing target env file: \$(basename "\$envfile")" + . \$envfile + done +fi EOF }