[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: [coyotos-dev] Coyotos Makefiles Dominique Quatravaux Sat Aug 12 19:23:45 2006

Jonathan S. Shapiro wrote:

>I'm aware of Peter's paper. The problem with his argument is that it
>fundamentally doesn't scale.
It does scale quite well enough for the Linux kernel actually. Is the
Coyotos source tree (sans gcc and other 3rd-party tools, see below)
significantly larger?

>Folks: recursive make is a religious argument.
You certainly make it sound so :-) since:

> I'm not open to changing
>that decision in the Coyotos tree.
and now for my attempt at an actually useful contribution :-): maybe the
term "Coyotos tree" needs clarification here. Do you count the 3rd-party
tools (e.g. gcc) as part of it? If so, then I would concur with you: so
as to re-use the existing build system of said 3rd-party tools, a
certain amount of recursive make is in order.

On the other hand, I'd still consider it a really ponder-worthy idea to
use a single Makefile for the part of the tree that you develop in-house
(especially if you have to build part of it twice for the sake of
cross-compilation, e.g. libgcc). An essential premise is that I don't
buy into asymptotic algorithmic complexity arguments *at all*, because
you aren't going to write a number of source files that approaches
infinity in any meaningful way. And neither will the rest of the world
on your behalf: when you'll want to open up your tree so that 3rd-party
programmers can e.g. add their own device drivers, you will undoubtedly
do so through well-defined interfaces for separate compilation (or even
ABI compatibility, if the stars are just right?), and therefore a
surrogate for "recursive make" will enter the picture again, just like
it did for Linux 2.6 3rd-party kernel modules. But until then, YAGNI

Sorry to sound authoritative for once, but Makefiles are much more
within my league than the stuff usually discussed on this list :-)


<< Tout n'y est pas parfait, mais on y honore certainement les jardiniers >>

                        Dominique Quatravaux <[EMAIL PROTECTED]>

coyotos-dev mailing list