Eric S. Raymond wrote:
> kbuild team members: Dirk Hohndel has volunteered to have a chat with
> Linus about the CML2/kbuild-2.5 transition (and, implicitly, the status
> and role of the kbuild team).
>
> Please inform him of:
>
> 1) your technical judgement and opinions about CML2 and kbuild-2.5
>
> 2) the problems with the present build system,
>
> 3) whether or not you think CML2 and kbuild-2.5 should be mainstreamed
> into the kernel,
>
> 4) known remaining problems with CML2 and kbuild-2.5, and what the plans
> are to address them.
>
> He needs to hear from the whole kbuild team and properly understand
> the background of our present rather frustrating situation.
>
kbuild-2.5:
It does the right things! And this should be enought to tell you that
it should be included in the next kernels.
Some more words:
Actual kbuild requires that user will do a make mrproper before
every patch (and sometime before big configuration changes).
So it will slow the things a lots.
[This cause troubles also on the user helper to compile the kernel
(debian 'kpackage' will always call make mrproper)].
The problem is also that the user that will not do make mrproper
will eventually see some strange link errors, and this confuse
users [and regulary someone will post a bug report in lkml, with
the regulary keith's one-line reponse.]
[and again with mrproper: I don't like the copy .config + mrproprt
+ restore .config ]
Another big improvment is that kbuild-2.5 doesn't touch non modified
files [i.e. the 'touch include/*/*.h;' commands (this caused problem
with cvs)]
It have been reported that kbuild-2.5 is slower, but I don't care
the speed of already slow process (and it is slower only the
first time), and Keith told us that it would increment the speed.
CML2:
In kbuild the problem was the correcness and to correct the old behaviour
it was necesary to change the language (and kbuild-2.5 was not the
unique project. It is the unique project completed, thus solved all the issues).
In CML2 I see more a problem of maintainability:
3 implementations (two bash based, which confise a lot of developer, which use
bashism): a lot of maintainers doesn't read the documentation and thus
made wrong configuration code (the two common errors: bashism and
assertion that defined CONFIG_ means "y" or "m").
The Linus' way to maintain the kernel incremented such problems.
CML2 solved the problems with one unique engine, a new language that
will force corectness, and a true rules check .
Another problem in old configuraion is that some configuration had
dependencies not yet parsed, which sometime caused wrong configuration,
but frequently user will miss some features.
But I don't know if this 'feature' is fixed in CML2: with the splitted
rules it can give some difficulties to rules implementators).
CML2 support also autoconfiguration, and I think this is a nice
things :-).
In last days of 1999 Linus (and that Alan) told that some kind of
autoconfiguration was need (the thread was about wrong CPU selection).
The autoconfiguration need CML2 (or a very big rewrite of the 3 actual
configuration engine).
The big problem in CML2 is python (and python2). This problem should go
away considering the development time of kernel, but anyway it is a problem.
[Actually seems easier to explain user hot to intall python than how
to intall the curse haeders (python package name is nearly unique)].
But we should also consider that Linus now unofficially recommend
bitkeeper, a worse package (non-free, no code).
Thus I think that kbuild-2.5 and CML2 should be included in the
kernels. build-2.5 because it do the right things, and CML2 because
it will help maintainers, developers and also Linus (no more, or
less patches of patches).
giacomo
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
