[PATCH] fix erroneous "builddir" reference in libbb/Makefile

[Paul Fox]

 > > > i have no problems telling people to stop using anything older than 3.80
 > > > ... at this point though, requiring 3.81 is too much imho
 > > >
 > > > maybe add this to a toplevel file somewhere:
 > > > ifneq ($(findstring 3.7,$(MAKE_VERSION)),)
 > > > $(error Your make is too old, please upgrade it to 3.80 or newer)
 > > > endif
 > >
 > > Just confirming: building on Red Hat 9 would be dropped then?
 > 
 > does red hat 9 prevent you from upgrading to a newer version of make?
 > 

speaking as someone using busybox in a commercial product, can i
point out that tool selection isn't always a simple decision.

[ what i'm going to say is actually somewhat hypothetical, since
it doesn't precisely match anything that we're actually currently
doing or shipping, but it's close.  ]

currently our shipping product runs busybox 1.00, with some
patches applied.  many of those patches have either been
contributed back, or are made obsolete by other fixes, or are
things we need but which wouldn't be generally useful.  but we
trip over 1.00 issues periodically, and enough work has been done
on busybox since 1.00 that we'd obviously be interested in
upgrading.

because our development machines run (you guessed it) RH9, and
the _rest_ of the product is stable with that toolchain level, it
would introduce some amount of risk or churn for us to upgrade
make.  so if the next busybox release were to require a new make
revision, it would discourage us from moving to the next busybox,
which would be frustrating.

now, as i said, this is somewhat hypothetical -- we're in the
process of bringing our build machines forward, we're actually
mainly interested in the new busybox for newer products, and, in
practice, a new version of make probably wouldn't break any of
our old product anyway -- far less likely than a compiler change,
say.  so if 3.80 becomes the new baseline, we'll deal.

the point is simply that there's value in maintaining a certain
amount of stability in the build tool requirements, and so far i
think busybox has done a good job at striking that balance.  i'm
sure ours isn't the only project that appreciates that.

paul
=---------------------
 paul fox, pgf at brightstareng.com