Build doesn't fail if od not installed
rob at landley.net
Fri Sep 17 18:14:28 UTC 2010
On Thursday 16 September 2010 06:23:03 Denys Vlasenko wrote:
> On Thu, Sep 16, 2010 at 10:58 AM, Harald Becker <ralda at gmx.de> wrote:
> > Hi!
> > I just had some really big trouble because of busybox build not failing
> > if od is not installed. The build throws a message about this but
> > otherwise it continues. As this goes that fast I didn't mention this
> > message and assumed those messages are only warnings ... but missing od
> > leads into trouble preparing the usage messages which gives a
> > segmentation fault as soon as you try to invoke "busybox APPLETNAME
> > --help" ... needed hours to find the reason for this!
> > Denys, can you fix this, so that a missing required program leads into a
> > build abort? Thx!
> Yes, can do. See attachment.
> But where should we stop?
I just throw a lot of "|| exit 1" into my scripts. I also note the bash "set
-o pipefail" option is useful at times.
My general assumption is that anything can break, because build environments
out there are crap, and they're all crap in slightly different ways. The
autoconf approach of trying to identify anything that can go wrong and cope is
hilariously stupid, what you do is break the build and let the person fix their
If you accept that the build is going to break _anyway_ (I.E. reality), all
the "|| exit 1" stuff does is break politely at the point the failure occured,
rather than making them waste time backtracking to find it. You don't have to
be perfect about this, but it's nice.
> od is part of the coreutils. The key part here is "core".
Given that the FSF named it, the "dump" is presumably implied.
> Should I also make build fail if dd is not available? Or sed? Or grep?
> Or cp? mv? rm? cat? mkdir?
Dude, I broke _echo_. (And so did ubuntu when they replaced #!/bin/sh to
point to the defective annoying shell and suddenly they lost the bash builtins
and were using /bin/echo which didn't support -n or -e. But I broke it
> Can you imagine how ugly the scripts would look which check
> for every one of these programs?
Autoconf is a tentacled abomination. Don't go there. It's entirely the wrong
approach: eliminate unnecessary environment dependencies, support a reasonable
level of granularity to switch stuff off, but beyond that try to work, give a
good error message when you don't, and let them fix their darn build
Running a test to make the build break in "configure" instead of in "make"
saves maybe a minute of compile time to give a slightly different error
message. The downside is a configure stage that serializes the build on non-
ubiquitous SMP systems, screws up cross compiling, and given time winds up the
most complicated part of your build by far testing for things nobody's seen in
years because only one guy ever hit and and there's no way to regression test
on systems you don't have. It is _not_ worth it.
Summary; It is not your problem to work around mingw being crazy, but breaking
expressively at the actual point of failure is nice.
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem
Forever, and as welcome as New Coke.
More information about the busybox