Re: [docs] [PATCH 5/5] sdk-manual/intro.rst: detail differences between standard and extensible sysroots

[Quentin Schulz <quentin.schulz@cherry.de>]

Hi Antonin,

On 7/31/26 10:56 AM, Antonin Godard wrote:
> Hi,
> 
> On Thu Jul 30, 2026 at 1:39 PM CEST, Quentin Schulz via lists.yoctoproject.org wrote:
>> Hi Antonin,
>>
>> On 7/29/26 12:02 PM, Antonin Godard via lists.yoctoproject.org wrote:
>>> The sysroot in the standard and the extensible SDKs are managed
>>> differently. Detail this in the Sysroots section.
>>>
>>> [YOCTO #14830]
>>>
>>> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
>>> ---
>>>    documentation/sdk-manual/intro.rst | 15 +++++++++++++++
>>>    1 file changed, 15 insertions(+)
>>>
>>> diff --git a/documentation/sdk-manual/intro.rst b/documentation/sdk-manual/intro.rst
>>> index 8ccbcfa20..2e5f73f0b 100644
>>> --- a/documentation/sdk-manual/intro.rst
>>> +++ b/documentation/sdk-manual/intro.rst
>>> @@ -123,6 +123,21 @@ sysroot is based on the target root filesystem image that is built by
>>>    the OpenEmbedded build system and uses the same metadata configuration
>>>    used to build the cross-toolchain.
>>>    
>>> +However, the extensible and standard SDKs sysroot differ in content:
>>> +
>>
>> Why did we stop referring to the Sysroot term (:term:`Sysroot`)?
> 
> I can keep referring to it, but thought the first reference was enough. Will try
> to refer to it when I can.
> 

I see it like our rule for using :term: for all variables, replace 
whenever we have a Yocto-specific term, be it in the glossary or not, 
use :term:/:ref: as much as possible.

Maybe at some point it'll be making it harder to read with all of those 
links being underlined but maybe we can worry at that point and figure 
out finer rules later on? What do you think?

>>> +-  The standard SDK sysroot only contains libraries and headers for the packages
>>
>> s/for/of/?
>>
>> I think we should also mention this brings the libraries and headers of
>> their dependencies (recursively) as well?
> 
> Correct, I'll add that
> 
>>> +   found in the :term:`TOOLCHAIN_TARGET_TASK` and :term:`TOOLCHAIN_HOST_TASK`
>>> +   definitions, for the target and native sysroots respectively.
>>> +
>>
>> I know we have a nativesdk OVERRIDE, so is it still a native/target
>> sysroot or should it be named nativesdk too (I've never built an SDK so
>> I don't know).
> 
> So here saying "native sysroot" makes sense if you're only look at the SDK.
> Under yocto it's true that we have a distinction between native and nativesdk,
> so maybe replacing "native" by "host" here would avoid the confusion in any
> case. Will do
> 

Yeah, we just have to be particularly careful when using "host" and 
"target" when meson is involved because it has a different meaning than 
what we have in Yocto.

>>> +   See :doc:`/sdk-manual/appendix-customizing-standard` to learn how to
>>> +   customize it.
>>> +
>>> +-  The extensible SDK sysroot is completely managed by the ``devtool``
>>
>> Can we maybe point at some docs for devtool? From a quick grep, maybe
>> something in documentation/ref-manual/devtool-reference.rst?
> 
> Agreed, will add that
> 
>>> +   command-line tool, and its content is the same as the sysroot of the image
>>> +   recipe for which the SDK was built.
>>> +
>>
>> I guess we could show how to do this here?
>>
>> I think it should be something like:
>>
>> bitbake my-image -c populate_sdk
>>
>> (or maybe point at
>> https://docs.yoctoproject.org/sdk-manual/appendix-obtain.html#building-an-sdk-installer
>> ?).
> 
> Since there are already references to appendix-obtain and appendix-customizing I
> think it's already enough?
> 

I see you added it in v2, thanks :)

Cheers,
Quentin