[GRLUG] Meeting agenda?

[Michael Mol]

On 10/11/06, Roberto Villarreal <rvillarreal at mktec.com> wrote:
> On Wednesday 11 October 2006 13:05, Michael Mol wrote:
> >
> > Not really.  The kernel build system does a decent job in keeping
> > compile times light.  If you've compiled the kernel before, and you
> > change a couple of options, the build system will compile only the
> > parts that have changed.
>
> Even that depends... for a fresh compile (assuming you get everything right
> the first, which for me is maybe 30% of the time), it is (on my machine) the
> difference between 9 minutes and 33 minutes.  And on your last comment, that
> is true, but you aren't assured that your kernel will be correct if you
> don't 'clean' between builds (I speak from experience here).
>
> My *guess* for this (and this is a guess, I haven't investigated) is that
> assuming that there is no magic other than what the 'make' system does, if
> you have a file named foo.c that has already been compiled, then as long as
> none of it's *file* dependencies have changed, it won't recompile.  But if
> foo.c has #IFDEFs for kernel options that have changed since the last build,
> if the actual files above it haven't changed because of the revised option,
> then foo.c won't be recompiled (which has 'new' code that becomes exposed as
> a result of the #IFDEF).

A good rule of thumb is, if you've changed an option which has
tendrils in large swaths of the kernel, use make clean.  Otherwise,
it's not usually necessary.  If, for example, you decide to enable
passing function arguments in the registers, you'll want to do a make
clean...that changes a gcc command line option without changing much
in the way of C code.

Modifying the scheduler timeslice, supported network protocols, and
most of the "General" options should be accompanied by a make clean.

-- 
:wq