[PATCH] standardize on KERNEL_VERSION(a,b,c) test
Rob Landley
rob at landley.net
Thu Mar 30 13:44:20 PST 2006
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.
More information about the busybox
mailing list