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

[Rob Landley]

On Thursday 30 March 2006 10:33 am, Robert P. J. Day wrote:
> On Thu, 30 Mar 2006, Bernhard Fischer wrote:
> > On Thu, Mar 30, 2006 at 07:51:04AM -0500, Robert P. J. Day wrote:
>
> ... snip ...
>
> > >diff -pru busybox.orig/e2fsprogs/mke2fs.c busybox/e2fsprogs/mke2fs.c
> > >--- busybox.orig/e2fsprogs/mke2fs.c	2006-03-29 07:43:43.000000000 -0500
> > >+++ busybox/e2fsprogs/mke2fs.c	2006-03-30 07:30:30.000000000 -0500
> > >@@ -33,6 +33,7 @@
> > > #include "e2p/e2p.h"
> > > #include "ext2fs/ext2fs.h"
> > > #include "util.h"
> > >+#include "platform.h"
> >
> > That include sounds wrong.
> > e2fsbb.h includes libbb.h which includes platform.h
>
>   hard to believe but i've been grappling with what to think about the
> layout of BB header files for a few days.
>
>   obviously, including "platform.h" is redundant but it doesn't hurt
> since all of the header files are protected against multiple inclusion
> so that's certainly not going to break anything, but there's more to
> it than that.
>
>   as it stands now, i think the BB header files are unnecessarily
> confusing simply because they're nested.  if you take a quick look at,
> say, libbb.h, it starts off with:
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <stdarg.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <termios.h>
> #include <stdint.h>

It needs to include at least a decent chunk of those for types uses as 
function arguments or global variables.  Once youv'e got enough of them, 
quibbling about the rest becomes a bit silly.

> so including libbb.h *already* drags in a number of system header
> files.  obviously, that means that, once you include "libbb.h", you no
> longer need to include any of the above, right?  and yet, if you pick
> a random source file under libbb/, chances are it will not only be
> including "libbb.h" but at least (redundantly) one of the above.  (in
> fact, i defy you to find a source file in libbb/ that doesn't contain
> that kind of redundancy).
>
>   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.

So we're annoying the author of that book, then.

> here's a perfect example of the chaotic structure of the current
> header files.  consider the source file libbb/error-msg.c
>
> ================================
> #include <stdio.h>
> #include <errno.h>
> #include <string.h>
> #include <stdlib.h>
> #include "libbb.h"
>
> void bb_error_msg(const char *s, ...)
> {
>     va_list p;
>
>     va_start(p, s);
> ...
>
>   first, as we've established, there's no need to include <stdio.h>
> since that's already included by "libbb.h".  but it's actually worse
> than that.  the "va_list" stuff is defined in <stdarg.h> but that file
> is *not* included by this source file.  no problem, though, since it
> comes via "libbb.h".
>
>   in effect, by letting "libbb.h" be this monstrous catch-all header
> file that grabs most everything else, it allows the programmer to be
> incredibly sloppy about which other header files to include.  yes, it
> works, but it just seems "messy" to me.

Are you proposing removing unnecessary #includes from headers other than 
libbb.h?  Shaun Jackman keeps trying to add more...

Or are you proposing that people should have to #include <stdlib> before they 
can #include "libbb.h" unless they want a build break?

> rday

Rob
-- 
Never bet against the cheap plastic solution.