Build doesn't fail if od not installed

[Rob Landley]

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

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

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

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.

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.