[Buildroot] [PATCH] docs/manual: document KBUILD_VERBOSE environment variable

Signed-off-by: Anton Leontiev <redacted>
---
 docs/manual/common-usage.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/docs/manual/common-usage.txt b/docs/manual/common-usage.txt
index 9ba87a8339..699a20fe40 100644
--- a/docs/manual/common-usage.txt
+++ b/docs/manual/common-usage.txt

@@ -69,6 +69,9 @@ to +make+ or set in the environment:
 
 * +HOSTCXX+, the host C++ compiler to use
 * +HOSTCC+, the host C compiler to use
+* +KBUILD_VERBOSE+, KBuild verbosity; it is essentially the same as specifying
+  +V=1+ in make arguments. If set, exports itself and +VERBOSE=1+ to all
+  subprocesses.
 * +UCLIBC_CONFIG_FILE=<path/to/.config>+, path to
   the uClibc configuration file, used to compile uClibc, if an
   internal toolchain is being built.

-- 
2.31.1

Anton, All,

Thanks for this contribution.

On 2021-04-19 19:03 +0300, Anton Leontiev spake thusly:

The naming of the KBUILD_VERBOSE variable is just an implementation
detail. That it has a similar purpose as a variable of the same name in
Kbuild (the linux kernel buildsystem) is just happenstance.

Buildroot is not using Kbuild, nor is it even remotely based on Kbuild.

After discussing among maintainers, we decided that we did not want to
officially expose that variable.

Regards,
Yann E. MORIN.

 * +UCLIBC_CONFIG_FILE=<path/to/.config>+, path to
   the uClibc configuration file, used to compile uClibc, if an
   internal toolchain is being built.
-- 
2.31.1

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

Yann E. MORIN [off-list ref]:

The naming of the KBUILD_VERBOSE variable is just an implementation
detail. That it has a similar purpose as a variable of the same name in
Kbuild (the linux kernel buildsystem) is just happenstance.

Buildroot is not using Kbuild, nor is it even remotely based on Kbuild.

After discussing among maintainers, we decided that we did not want to
officially expose that variable.

Then maybe it's better to rename this variable into something like
BR2_VERBOSE?

-- 
Anton Leontiev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20210428/4144b0bc/attachment.html>

quoted

quoted

quoted

quoted

"Anton" == Anton Leontiev [off-list ref] writes:

 > Yann E. MORIN [off-list ref]:
 >> The naming of the KBUILD_VERBOSE variable is just an implementation
 >> detail. That it has a similar purpose as a variable of the same name in
 >> Kbuild (the linux kernel buildsystem) is just happenstance.
 >> 
 >> Buildroot is not using Kbuild, nor is it even remotely based on Kbuild.
 >> 
 >> After discussing among maintainers, we decided that we did not want to
 >> officially expose that variable.
 >> 

 > Then maybe it's better to rename this variable into something like
 > BR2_VERBOSE?

Perhaps. What is your use case for wanting to use an environment
variable instead of the normal V=1 make argument?

-- 
Bye, Peter Korsgaard

Peter Korsgaard [off-list ref]:

quoted

Then maybe it's better to rename this variable into something like
BR2_VERBOSE?

Perhaps. What is your use case for wanting to use an environment
variable instead of the normal V=1 make argument?

I have a Jenkins job, which builds Buildroot. I want to add a job
parameter to enable verbose output. Jenkins job parameters are
automatically exposed as environment variables. So I've named it
KBUILD_VERBOSE and that's all, I shouldn't change any commands.

-- 
Anton Leontiev