LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Keith Owens <kaos@ocs.com.au>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Jeff Garzik <jgarzik@mandrakesoft.com>, linux-kernel@vger.kernel.org
Subject: Re: [patch] 2.4.11-pre4 remove spurious kernel recompiles
Date: Mon, 08 Oct 2001 10:42:56 +1000	[thread overview]
Message-ID: <29190.1002501776@kao2.melbourne.sgi.com> (raw)
In-Reply-To: Your message of "Mon, 08 Oct 2001 02:05:44 +0200." <20011008020544.K726@athlon.random>

On Mon, 8 Oct 2001 02:05:44 +0200, 
Andrea Arcangeli <andrea@suse.de> 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))))
>> FILES_FLAGS_UP_TO_DATE += 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.

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

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
SUBLEVEL.


  reply	other threads:[~2001-10-08  0:42 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 [this message]
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=29190.1002501776@kao2.melbourne.sgi.com \
    --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).