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: linux-kernel@vger.kernel.org
Subject: Re: [patch] 2.4.11-pre4 remove spurious kernel recompiles
Date: Mon, 08 Oct 2001 12:49:25 +1000	[thread overview]
Message-ID: <440.1002509365@kao2.melbourne.sgi.com> (raw)
In-Reply-To: Your message of "Mon, 08 Oct 2001 04:12:15 +0200." <20011008041215.O726@athlon.random>

On Mon, 8 Oct 2001 04:12:15 +0200, 
Andrea Arcangeli <andrea@suse.de> wrote:
>On Mon, Oct 08, 2001 at 11:34:04AM +1000, Keith Owens wrote:
>The main thing I like is to be able to compile out of the tree and
>avoiding touching the header files during compilation (that's really
>annoying).

All fixed in kbuild 2.5.

>I personally don't care about correctness in the sense of getting "make"
>doing everything for you regardless of what you changed, I'm fine with
>some "make distclean" forced checkpoint after PATCHLEVEL changed etc...,
>you said infact full compile is needed sometime, not to tell about
>kernel configuration.

Strongly disagree.  One of the biggest problems with kbuild is the user
who applies a patch and expects the kernel to automatically rebuild
just the bits that are affected.  We must not rely on every user doing
make distclean or mrproper after applying a patch, we know that does
not happen, resulting in inconsistent kernels.  If you want to do a
complete recompile after a patch that is your choice, but we cannot
rely on the entire user population doing that.  kbuild must be
automatic and correct.

>One good example is the mkdep hack, it's far from correct: the header
>dependences is nearly random.  We cannot trust it unless we remeber
>every user included us (one more reason I'm used to full recompiles),

Absolutely agree.  The design assumption for mkdep is that the source
and/or .config do not change after make dep.  That might have been true
once but with several kernel trees, separate arch patches, separate sub
system patches and compiling for multiple configurations it is not true
now.  kbuild 2.5 completely redesigned the dependency tree and gets it
right!

However we are getting off the original patch which removes spurious
compiles from the existing system.


  reply	other threads:[~2001-10-08  2:49 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
2001-10-08  1:34             ` Keith Owens
2001-10-08  2:12               ` Andrea Arcangeli
2001-10-08  2:49                 ` Keith Owens [this message]
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=440.1002509365@kao2.melbourne.sgi.com \
    --to=kaos@ocs.com.au \
    --cc=andrea@suse.de \
    --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).