Re: [bitbake-devel] [PATCH] doc: document dependency tracking associated with addpylib

["Antonin Godard" <antonin.godard@bootlin.com>]

On Tue Oct 13, 2026 at 11:56 AM CEST, Yann Dirson via lists.openembedded.org wrote:
>
>
> On 10/12/26 3:20 PM, Antonin Godard wrote:
>> On Mon Oct 12, 2026 at 3:08 PM CEST, Antonin Godard via lists.openembedded.org wrote:
>>> Hi,
>>>
>>> On Mon Oct 12, 2026 at 10:25 AM CEST, Yann Dirson via lists.openembedded.org wrote:
>>>> Reported-by: Claude Opus 5.5
>>>> Signed-off-by: Yann Dirson <yann.dirson@vates.tech>
>>>> ---
>>>>   doc/bitbake-user-manual/bitbake-user-manual-metadata.rst | 8 ++++++++
>>>>   1 file changed, 8 insertions(+)
>>>>
>>>> diff --git a/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst b/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst
>>>> index 621aab253..eef1f9624 100644
>>>> --- a/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst
>>>> +++ b/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst
>>>> @@ -2264,6 +2264,14 @@ The specified <namespace> is imported automatically, and if the imported
>>>>   module specifies an attribute named ``BBIMPORTS``, that list of
>>>>   sub-modules is iterated and imported too.
>>>>   
>>>> +Additionally, Bitbake will detect usage of functions from such a
>>>> +library and include them in task hashes, so changes in those functions
>>>> +trigger task rebuilds.  Note that only functions inside modules
>>>> +declared using ``BBIMPORTS`` benefit from this dependency tracking,
>>>> +any name defined directly in the specified namespace (e.g. in
>>>> +`<namespace>/__init__.py`, or in a library hat would be defined as
>>>
>>> s/hat/that/
>>>
>>>> +`<namespace>.py`) would *not* benefit from this tracking.
>>>
>>> Otherwise, this is clear to me. I did not know about this limitation/feature,
>>> and this is definitely important to document, thanks!
>> 
>> Reading the code[1], it seems that functions prefixed with _ are not included
>> in the task checksums - if I understood correctly. I think it would be also
>> important to mention that. Could you add it in a v2?
>
> It could be asked why we would want to exclude them.  Usually that would 
> be internal functions, to be called by the exported ones, so they would 
> equally matter - but then they are actually not included in the task 
> hash, so it rather looks like a bug rather than something to document?

You're right, it seems strange to exclude them entirely. You may want to send a
patch to remove this then? At least it will kick-off the discussion on this
list.

Thanks,
Antonin