LKML Archive on
help / color / mirror / Atom feed
From: Andrea Arcangeli <>
To: Keith Owens <>
Cc: Jeff Garzik <>,
Subject: Re: [patch] 2.4.11-pre4 remove spurious kernel recompiles
Date: Mon, 8 Oct 2001 03:20:23 +0200	[thread overview]
Message-ID: <20011008032022.M726@athlon.random> (raw)
In-Reply-To: <20011008020544.K726@athlon.random> <>
In-Reply-To: <>; from on Mon, Oct 08, 2001 at 10:42:56AM +1000

On Mon, Oct 08, 2001 at 10:42:56AM +1000, Keith Owens wrote:
> On Mon, 8 Oct 2001 02:05:44 +0200, 
> Andrea Arcangeli <> wrote:
> >On Mon, Oct 08, 2001 at 09:29:06AM +1000, Keith Owens wrote:
> >> 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))))
> >> endif
> >
> >Ok, so the point of all those .flags is to catch per-object cflags changes.
> It catches all cflags changes, from global CFLAGS, per directory cflags
> and per object cflags.  I repeat, you do not need to detect changes to
> the top level Makefile in order to detect cflag changes.

Sure I understand that.

> >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.
> Of course it works.  EXTRAVERSION is only a human readable string used
> by 15 sources (via UTS_RELEASE) and by the various logo.h files.
> Changing EXTRAVERSION has no effect on executable code, it only affects
> display fields.  Any other files changed at the same time as
> EXTRAVERSION (say by a patch) will be recompiled, based on the
> timestamp changes.  Adding a patch which changes EXTRAVERSION does not
> require a full recompile, which is why the existing system is broken.

I didn't expected it to work including module versioning without a full
recompile, but good to know.

> I admit that kbuild 2.4 does not correctly handle changes to CC, if you
> "make CC=gcc" then "make CC=kgcc", the kernel is not rebuilt.  You must
> manually make distlean or mrproper when changing CC.  Note that
> overriding flags on the command line does not change the Makefile so
> you cannot rely on the Makefile timestamp to detect command changes,
> IOW a check for Makefile timestamp is both overkill (it recompiles too
> much) and incomplete (it does not detect command line overrides).  BTW,
> kbuild 2.5 gets this right.

That sounds fine. Of course the only regression could be the build time.
Do you have a benchmark on the build time with kbuild 2.5 applied to
2.4.10 compared to the build time of 2.4.10?

> module.h currently uses the full UTS_RELEASE which includes
> EXTRAVERSION but that is spurious, modutils ignores EXTRAVERSION when
> loading a module.  modutils only cares about VERSION, PATCHLEVEL and

Well again EXTRAVERSION was just an example, SUBLEVEL was the same
problem as EXTRAVERSION for me, I mean after you apply an -ac patch that
for example goes backwards in the SUBLEVEL, do you recompile everything
or do you just run make after your Makefile patch is applied to the


  reply	other threads:[~2001-10-08  1:21 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
2001-10-08  0:42         ` Keith Owens
2001-10-08  1:20           ` Andrea Arcangeli [this message]
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20011008032022.M726@athlon.random \ \ \ \ \

* 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).