[PATCH] standardize on KERNEL_VERSION(a,b,c) test

[Allan Clark]

On 3/31/06, Rob Landley <rob at landley.net> wrote:
> On Friday 31 March 2006 10:34 am, Allan Clark wrote:
> > On 3/30/06, Robert P. J. Day <rpjday at mindspring.com> wrote:
> > > On Thu, 30 Mar 2006, Bernhard Fischer wrote:
> > > [...]
> > >   so what to do about all of *that* then?  coincidentally, just a few
> > > weeks ago, i was reading a software design book that *strongly*
> > > discouraged the concept of nested header files.  its advice was that:
> > >
> > > 1) each header file should have a clear and focused purpose,
> > > 2) each source file should include precisely those header files that
> > >    it needs and no more, and
> > > 3) you shouldn't create humongous, catch-all header files (like
> > >    busybox.h and libbb.h) whose only purpose is to let you be somewhat
> > >    lazy about having to list the includes you really need.
> >
> > FWIW, it's a bit of an isolated example, but using Clearcase
>
> is a mistake.  (I've used it.  Never actually accomplished anything with it,
> but I sat there fighting with it...)

a 10-hr build becomes a 2-hr build.
a 6-hr build becomes a 1-hr build

Numbers speak volumes.  Oh, and we share builds, like a distcc
combined with something like a broadcast ccache.  ...but maybe build
time makes no difference.  Oh, and we don't necessarily have to "make
clean", clearcase remembers that for us, but we do production builds
from-clean anyways.


> > and Clearmake, catch-all headers really impede the build-avoidance.
>
> Our current dependency generation isn't doing that great a job with it either.
>
> > I'm
> > not saying that the world uses/should-use clearmake, or that the
> > example has a lot of bearing, but catch-all headers, even it caught in
> > dependencies of ... gcc -MD, that kind of thing -- it causes needless
> > recompile.  That's no issue when your build is the 30-second job my
> > cheap little hacks are worth, but the current 6-hr "LinuxJava" build
> > my current employer has, this kind of thing becomes an issue.
>
> I have no immediate interest in solving this non-problem, but if somebody else
> does I'm not standing in their way.  (I expect the build to break repeatedly
> in the process, in ways it's not breaking now, and I expect the benefits of
> the results to be hard to measure.  I'm not exactly enthusiastic about it.
> But other than needless churn I don't see anything _wrong_ with it, per
> se...)

It is an issue, though.  The fewer unnecessary headers, the fewer
rebuilds when a header changes.


> > Problem is, what happens when a header uses a type defined in another
> > header?
>
> Which libbb is doing extensively.
>
> > Seems there are two options:
> >
> > 1) include that header (we're avoiding that, right?), or
> > 2) fail if that header's sentry is not found.
>
> If you have to check for the header's sentry, just #include the darn header.
> They're all surrounded by guards.

"we're avoiding that, right?" above.  I do see the logic that I
missed: if you need it, then either it's included by the original *.c
file, or you include it at the header that uses its types.  My bad. :(

[...]

I still push for reducing the headers you don't need -- I'll do it
myself if no one else wants to, if I have some assurance it'll get
merged.  It allows build-avoidance things like clearmake and the
.deps/* files that gcc can create, and doesn't hurt the cases where
this kind of thing is not done.

Allan