Bug 15746

Summary: BB_CMDLINE undocumented
Product: [Documentation] BitBake User Manual Reporter: kweihmann
Component: bitbake-manualAssignee: Swaminathan K <swami310>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: Medium CC: antonin.godard, dixitparmar19, randy.macleod, swami310
Version: unspecified   
Target Milestone: 5.99   
Hardware: x86   
OS: Multiple   
Whiteboard: NEWCOMER
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: Yes (doc changes required)

Description kweihmann 2025-02-16 10:08:34 UTC
BB_CMDLINE set by bitbake and used by buildhistory is lacking a documentation
Comment 1 Dixit Parmar 2025-07-02 12:53:17 UTC
At first glance, BB_CMDLINE variable is set by cooker.py based on the bitbake instance run as a command line, and that variable is largely used by buildhistory purposes. However, I did not find any instances or use cases to manually specify BB_CMDLINE, with that understanding - Do we document this internally used variable? If yes, Is ref-manual variables is right place?
Comment 2 Antonin Godard 2025-07-02 13:38:11 UTC
(In reply to Dixit Parmar from comment #1)
> At first glance, BB_CMDLINE variable is set by cooker.py based on the
> bitbake instance run as a command line, and that variable is largely used by
> buildhistory purposes. However, I did not find any instances or use cases to
> manually specify BB_CMDLINE, with that understanding - Do we document this
> internally used variable? If yes, Is ref-manual variables is right place?

Hi,

Indeed, OE-Core is only a consumer of this variable from what I can see. This variable belongs to the document of Bitbake, which is separate from OE-Core.

This documentation is part of the Bitbake repo, and the variables are documented here:
https://git.openembedded.org/bitbake/tree/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst

Also: BitBake documentation should _not_ make references to OE-Core, so you can try documenting it with only the scope of the BitBake source code in mind.

Additionally, you can document it in yocto-docs as follows:

   :term:`BB_CMDLINE`
      See :term:`bitbake:BB_CMDLINE` in the BitBake manual.

Thanks!
Antonin
Comment 3 Dixit Parmar 2025-07-16 03:25:56 UTC
Thanks Antonin.
As we understand BB_CMDLINE is under-the-hood variable, used by bitbake internally and its not possible to explicitly define it, it just contain what have provided as bitbake command. With understanding, I feel we should not have such variables documented and exposed to user to avoid confusion. What you think?
Comment 4 Antonin Godard 2025-07-22 11:50:34 UTC
(In reply to Dixit Parmar from comment #3)
> Thanks Antonin.
> As we understand BB_CMDLINE is under-the-hood variable, used by bitbake
> internally and its not possible to explicitly define it, it just contain
> what have provided as bitbake command. With understanding, I feel we should
> not have such variables documented and exposed to user to avoid confusion.
> What you think?

I think it's ok to document this variable but it needs to clearly mention that is is read-only.
Comment 5 Swaminathan K 2025-12-01 00:41:51 UTC
A  package  can be built in multiple ways:

As a Dependency (Indirectly Requested)
Explicitly requested ( directly)

A developer looking at the history needs to know if a build failure  was caused by:

A global change: Did someone change a setting in local.conf that affected all builds (which BB_CMDLINE would show by reflecting the standard image build command)?
A targeted rebuild: Did someone run a specific, potentially experimental, command just for that one package?

The BB_CMDLINE variable provides this specific audit trail within the build history logs.

BB_CMDLINE is an internal variable and is read-only. It captures the exact command line used for the current invocation of bitbake .
Comment 6 Antonin Godard 2025-12-01 09:45:22 UTC
Hi Swaminathan K, thanks for the reply and help.

(In reply to Swaminathan K from comment #5)
> A  package  can be built in multiple ways:
> 
> As a Dependency (Indirectly Requested)
> Explicitly requested ( directly)
> 
> A developer looking at the history needs to know if a build failure  was
> caused by:
> 
> A global change: Did someone change a setting in local.conf that affected
> all builds (which BB_CMDLINE would show by reflecting the standard image
> build command)?
> A targeted rebuild: Did someone run a specific, potentially experimental,
> command just for that one package?

I think the above is a bit too verbose for this variable, it can be kept short and simple by leaving only what's below.

> The BB_CMDLINE variable provides this specific audit trail within the build
> history logs.

Which log file are you talking about?
 
> BB_CMDLINE is an internal variable and is read-only. It captures the exact
> command line used for the current invocation of bitbake .

This is fine to me and IMO this could be shortened to this sentence only. 

To move forward, you need to send a patch to the bitbake-devel mailing: bitbake-devel@lists.openembedded.org.
You would need to modify this file: https://git.openembedded.org/bitbake/tree/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst
Please read the contributor guide to learn how to send patches via email: https://docs.yoctoproject.org/contributor-guide/submit-changes.html 

Keep in mind that we need to document this in BitBake's variable glossary. Those are definitions more that tutorial / guides.

Thanks!
Antonin
Comment 7 Swaminathan K 2025-12-02 05:35:24 UTC
thanks Antonin ! I will keep it short like this :

BB_CMDLINE is an internal variable and is read-only. It captures the exact
command line used for the current invocation of bitbake 


---
I am a novice and I would need some help with the steps to update the document. I am not sure if this is the place to ask for. Kindly point me to the right place where I can update
Comment 8 Swaminathan K 2025-12-02 05:49:18 UTC
To clarify, I have read through the contributor guide but still not clear how to make the changes :(. Kindly bear with me and point to any step by step instruction for a novice like me.