LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Keith Owens <kaos@ocs.com.au>
To: Jeff Garzik <jgarzik@mandrakesoft.com>
Cc: Andrea Arcangeli <andrea@suse.de>, linux-kernel@vger.kernel.org
Subject: Re: [patch] 2.4.11-pre4 remove spurious kernel recompiles
Date: Mon, 08 Oct 2001 09:29:06 +1000 [thread overview]
Message-ID: <27710.1002497346@ocs3.intra.ocs.com.au> (raw)
In-Reply-To: Your message of "Sun, 07 Oct 2001 13:16:19 EST." <Pine.LNX.3.96.1011007131234.26881H-100000@mandrakesoft.mandrakesoft.com>
On Sun, 7 Oct 2001 13:16:19 -0500 (CDT),
Jeff Garzik <jgarzik@mandrakesoft.com> wrote:
>On Sun, 7 Oct 2001, Andrea Arcangeli wrote:
>
>> On Sun, Oct 07, 2001 at 08:25:42PM +1000, Keith Owens wrote:
>> > in the top level Makefile forces a recompile of the entire kernel, for
>> > no good reason.
>>
>> this is a matter of taste but personally I believe that at least
>> theorically recompiling the whole kernel if I add -g to CFLAGS, or if I
>> change the EXTRAVERSION have lots of sense.
>
>Correct. I am amazed Keith missed this... changing data in Makefile
>can certainly affect the entire kernel compile, so it makes sense to
>recompile the entire kernel when it changes.
I did not miss it. Changing cflags is detected by the
.<object>.o.flags files.
ifeq (-D__KERNEL__ -I/build/kaos/2.4.11-pre4/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i586,$(strip $(subst $(comma),:,$(CFLAGS) $(EXTRA_CFLAGS) $(CFLAGS_vt.o))))
FILES_FLAGS_UP_TO_DATE += vt.o
endif
kbuild already detects changes to flags, down to the level of
per-object flags, there is no need to detect changes to the top level
Makefile. Especially when you can override flags and other fields on
the make command line, that does not change Makefile but kbuild still
detects the changes.
next prev parent reply other threads:[~2001-10-07 23:29 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-07 10:25 [patch] 2.4.11-pre4 remove spurious kernel recompiles Keith Owens
2001-10-07 18:05 ` Andrea Arcangeli
2001-10-07 18:16 ` Jeff Garzik
2001-10-07 23:29 ` Keith Owens [this message]
2001-10-08 0:05 ` Andrea Arcangeli
2001-10-08 0:42 ` Keith Owens
2001-10-08 1:20 ` Andrea Arcangeli
2001-10-08 1:34 ` Keith Owens
2001-10-08 2:12 ` Andrea Arcangeli
2001-10-08 2:49 ` Keith Owens
2001-10-08 3:07 ` Andrea Arcangeli
2001-10-08 17:56 ` bill davidsen
2001-10-08 16:19 ` bill davidsen
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=27710.1002497346@ocs3.intra.ocs.com.au \
--to=kaos@ocs.com.au \
--cc=andrea@suse.de \
--cc=jgarzik@mandrakesoft.com \
--cc=linux-kernel@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).