Re: State of the new config & build system

[Keith Owens <kaos@ocs.com.au>]

On Fri, 28 Dec 2001 14:17:24 -0800 (PST), 
Linus Torvalds <torvalds@transmeta.com> wrote:
>
>On Fri, 28 Dec 2001, Legacy Fishtank wrote:
>>
>> I think one thing to note is that dependencies is that if you are smart
>> about it, dependencies -really- do not even change when your .config
>> changes.
>
>Absolutely. I detest "gcc -MD", exactly because it doesn't get this part
>right. "mkdep.c" gets this _right_.

Sorry, it does not.  Everybody is attacking little bits of the
dependency problem, any solution that does not fix _all_ 9 problems in
http://prdownloads.sourceforge.net/kbuild/kbuild-2.5-history.tar.bz2,
makefile-2.5_make_dep.html is not a complete fix.

Yes, some of the problems with mkdep can be fixed in the current design
but there is one problem that is inherently unfixable.  make dep is a
manual process so it relies on users knowing when they have to rerun
make dep AND THEY DON'T DO IT!  Please do not say "I always run make
dep" after a change, I guarantee that you are the exception.  Users
apply patches and do not run make dep, then wonder why their kernel is
broken.

Dependencies _do_ change when your .config changes, the list of files
that are included varies.  gcc -MD gets this exactly right, gcc knows
which files it read.  mkdep does an incorrect approximation, see tyhe
bug list in makefile-2.5_make_dep.html.

The errors in mkdep were acceptable as long as only kernel hackers
built their own kernels, they could be relied upon to manually run
commands when necessary.  The target population has changed, more and
more beginners are building kernels and too many are getting it wrong.
I am aiming at the entire population, not that small subset who have
been building kernels since the year dot.

Any build system that silently fails when users forget to run a command
is a broken system.  kbuild 2.5 fixes _all_ 9 problems with mkdep, it
also positions us for correct modversion handling.  kbuild 2.4 is
faster, inaccurate and manual, kbuild 2.5 is slower, accurate and
totally automatic.

I know how to speed up 2.5.  What I don't have is time to rewrite the
code for speed, I am too busy tracking kernel changes because kbuild
2.5 is not in the kernel yet.

Linus, you have a choice between a known broken build system and a
clean and reliable system, which is slightly slower in mark 1.  Please
add kbuild 2.5 to the kernel, then I will have time to rewrite the core
programs for speed.  Mark 2 of the core code will be significantly
faster.

ps. I don't want mail discussing individual bug fixes to mkdep.  Code
    that does not fix _all_ 9 bugs listed in makefile-2.5_make_dep.html
    is pointless.