From: Andrea Arcangeli <andrea@suse.de>
To: Keith Owens <kaos@ocs.com.au>
Cc: Jeff Garzik <jgarzik@mandrakesoft.com>, linux-kernel@vger.kernel.org
Subject: Re: [patch] 2.4.11-pre4 remove spurious kernel recompiles
Date: Mon, 8 Oct 2001 02:05:44 +0200 [thread overview]
Message-ID: <20011008020544.K726@athlon.random> (raw)
In-Reply-To: <Pine.LNX.3.96.1011007131234.26881H-100000@mandrakesoft.mandrakesoft.com> <27710.1002497346@ocs3.intra.ocs.com.au>
In-Reply-To: <27710.1002497346@ocs3.intra.ocs.com.au>; from kaos@ocs.com.au on Mon, Oct 08, 2001 at 09:29:06AM +1000
On Mon, Oct 08, 2001 at 09:29:06AM +1000, Keith Owens wrote:
> 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
Ok, so the point of all those .flags is to catch per-object cflags changes.
> 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.
CFLAGS was only an example, think if I change CC or EXTRAVERSION, but, as
said in the earlier email, I doubt an EXTRAVERSION change would work
without a full distclean in between anyways.
Andrea
next prev parent reply other threads:[~2001-10-08 0:07 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
2001-10-08 0:05 ` Andrea Arcangeli [this message]
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=20011008020544.K726@athlon.random \
--to=andrea@suse.de \
--cc=jgarzik@mandrakesoft.com \
--cc=kaos@ocs.com.au \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.