| Summary: | BB_CMDLINE undocumented | ||
|---|---|---|---|
| Product: | [Documentation] BitBake User Manual | Reporter: | kweihmann |
| Component: | bitbake-manual | Assignee: | 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
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? (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 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? (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. 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 . 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 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 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. |