From: Milton Miller <miltonm@bga.com>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>, linux-kernel@vger.kernel.org
Subject: Re: [KBUILD] optionally print cause of rebuild (#2)
Date: Wed, 5 Jul 2006 12:20:36 -0500 [thread overview]
Message-ID: <9b18ca2d60e3c9a0ffc592b56cfee206@bga.com> (raw)
In-Reply-To: <20060705093056.GA9906@mars.ravnborg.org>
On Jul 5, 2006, at 4:30 AM, Sam Ravnborg wrote:
> Hi Milton.
>
> On Wed, Jul 05, 2006 at 02:01:26AM -0500, Milton Miller wrote:
>> Al wanted to see why Kbuild wanted to build files, to help debug
>> Makefiles or dependency chains.
> I like the idea and I have played around with it a bit before.
> To keep noise level down the "why got it rebuild" info should be on
> same
> line as the CC command and to trigger it increasing verbose level to 2
> seems more natural.
>
> Following patch does this.
> The patch contains a few clean-ups to make the "why" part slimmer.
>
> Comments?
You gave priority of dependent files while I gave priority to command
change. This is a judgment call, both are actually correct, but I
chose command change because changing the config will always cause
the built-in.o to be rebuilt even if you turned something back on
that you had off for a while.
You removed the subtle marker ('of') that said "here is a list of files"
vs some descriptive text (cmd change, etc); that means machine parsing
scripts have to recognize all the strings in why.
Printing it with the command like this is more compact, as long as we
enforce the rule that quiet_xxx_cmd will be of the format TAG file to
allow machine parsing. However, it does mean that for things built with
a rule, one has to figure out why the command was invoked.
For example, mine printed
DEPS: building .tmp_vmlinux1 because of drivers/built-in.o
GEN .version
CHK include/linux/compile.h
UPD include/linux/compile.h
DEPS: building init/version.o because of include/linux/compile.h
CC init/version.o
DEPS: building init/built-in.o because of init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
while yours does
GEN .version - due to: drivers/built-in.o
CHK include/linux/compile.h
UPD include/linux/compile.h
CC init/version.o - due to: include/linux/compile.h
LD init/built-in.o - due to: init/version.o
LD .tmp_vmlinux1 - due to: drivers/built-in.o
One might wonder how .version depends on drivers/built-in.o, and
why tmp_vmlinux1 wasn't built for init/built-in.o.
We should add this to make help.
milton
prev parent reply other threads:[~2006-07-05 17:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-04 21:57 Milton Miller
2006-07-05 7:01 ` [KBUILD] optionally print cause of rebuild (#2) Milton Miller
2006-07-05 9:30 ` Sam Ravnborg
2006-07-05 17:20 ` Milton Miller [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9b18ca2d60e3c9a0ffc592b56cfee206@bga.com \
--to=miltonm@bga.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sam@ravnborg.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome