* Arnaldo Carvalho de Melo <a...@ghostprotocols.net> wrote:
> Em Thu, Sep 12, 2013 at 11:10:37AM -0700, Linus Torvalds escreveu:
> > On Thu, Sep 12, 2013 at 11:03 AM, Linus Torvalds
> > <torva...@linux-foundation.org> wrote:
> > > When I compiled "perf" at the same time as doing a big kernel compile,
> > > the kernel compile failed
>
> > Oops. That may actually have been me being a bit *too* eager with a
> > "make allmodconfig" build. I can't reproduce it, and I'm starting to
> > suspect that I instead had two kernel compiles going, not one kernel
> > compile and a tools/perf/ compile.
>
> > "Yo Dawg, I heard you like kernel compiles, so I put a kernel
> > compile in your kernel compile so that you can compile the kernel
> > while you compile the kernel".
>
> :-)
>
> > But at least the "make install" problem is repeatable, though.
>
> Well, I just tried it, and the only thing that gets rebuilt are the CHK
> environment tests that try to figure out what can be built into perf,
> i.e. perl, python, libaudit, etc.
>
> Its something that annoys me as well, but not so much as to make me
> figure out how to make those be done only if some source file changed.
>
> But then, if you remove, say, libelf from your system so that you get a
> perf tool that uses just /proc/kallsyms, it wouldn't detect it...
I don't think package removal is a particularly common usecase.
> Perhaps in that case we should say: want a new build with a different
> environment? Do a 'make clean' first.
Exactly. The most common pattern is:
make
# see warnings about missing dependencies
install missing packages
make
# no warnings, happy camper
Downgrades, package removals almost never happen in real life, let alone
in typical build flows.
So in the simplest approximation, if we detected just the best-case: 'all
libraries are present, we can do a full build' case and cached that fact
across builds (and cleared the cached flag on 'make clean'), that would
help speeding up the main usecase already.
But a cached flag per _successful_ config/feature-tests.mak testcase would
work well too. I.e. only repeat checks that failed in the past. Once it
succeeds there's no need to re-check.
Independent of all this is the the bug of repeat checks Linus noticed,
that's indeed annoying and should be fixed separately of any feature test
cache.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
