Build doesn't fail if od not installed

Harald Becker ralda at gmx.de
Thu Sep 16 12:08:38 UTC 2010


 Hi!
> Yes, can do. See attachment.
Thx ... I'm trying to install that patch ... but that's a bit difficult
(not on machine, which received mail ... has to be exported/transfered =
several manual steps)

> But where should we stop?
Denys, we should never stop to check for errors. Especially on a build.
If any required program is missing/or fails during execution, we should
stop and report the error ... accept, we are able to handle the error
situation.

> od is part of the coreutils. The key part here is "core".
I don't like od.
I don't use od.
I don't like to have things hanging around which don't get used.
--> I kicked od off.

That's it. I didn't complain about using od. It was easily to fix after
detection of the failure reason. I'm just complaining about, busy not
failing it's build on a missing program.

> Should I also make build fail if dd is not available? Or sed? Or grep?
> Or cp? mv? rm? cat? mkdir?
Yes, you should. At every single program used! Accept you catch the
error and fix it in any way, e.g. use a different program available.

I know it looks ugly, that I kicked of that od, but I'm going to install
a production machine not a fully fledged development environment. I
don't want to have the machine over crowed with dozens of programs never
used. Less stuff on the machines make things simpler and easier to
overlook if everything is alright. That so many packages think, they
have to install plenty of extra stuff, which I don't need, is what I do
at most hate about those distributions. I don't want to have every
utility hanging around, which may eventually be useful in some rare
corner cases.

... and: It's my machine, it's my decision which things I want to have
installed. It's just a kind of philosophy of how to avoid possible flaws
... keep things simple and small. Less stuff = less possible flaws.

> Can you imagine how ugly the scripts would look which check
> for every one of these programs?
I know very well. The required error catching and reporting is always
the lengthiest part of scripts (I have just written a 50k bash
script)... but there are mechanisms to easy this. No one requires to do
sophisticated error handling in those situations. Just abort the build
with a none zero exit code.

Imagine this on shell scripts (if you are not using set -e):

fail() { exit 1; }; any_command || fail; next_command || fail; ...

... that doesn't make things too complicated. And make should abort as
soon, as any command returns a non zero value.

That's all I expect.

--
Harald



More information about the busybox mailing list