LKML Archive on lore.kernel.org help / color / mirror / Atom feed
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 03:20:23 +0200 [thread overview] Message-ID: <20011008032022.M726@athlon.random> (raw) In-Reply-To: <20011008020544.K726@athlon.random> <29190.1002501776@kao2.melbourne.sgi.com> In-Reply-To: <29190.1002501776@kao2.melbourne.sgi.com>; from kaos@ocs.com.au 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 <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. 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 > SUBLEVEL. 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 kernel? Andrea
next prev parent 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: 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=20011008032022.M726@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: linkBe 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).