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

[Rob Landley]

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...)

> 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...)

> 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.

> A header that needs to have this foo.h included before it -- rather
> than include foo.h itself -- can simply:
>
> #ifndef FOO_H
> #error need to include foo.h before this header
> #endif

That's evil, and ugly, and has absolutely no advantages that I can see.  
You've increased the complexity and still _have_ the dependencies, you're 
just hiding it from your dependency checker.

> A bit harsh, but it performs a check that describes (somewhat) the
> failure before it's something less-obvious like "undefined uint8", and
> doesn't affect the size of the resulting binary.

No.  Ick.  Evil.  Caution severe tire damage.  Dog eats anything and is fond 
of children.

Rob
-- 
Never bet against the cheap plastic solution.