[BusyBox] multibuild.pl vs. busybox.REGRESS.sh, and libraries

[Erik Andersen]

On Wed Jan 24, 2001 at 04:40:24PM -0800, Larry Doolittle wrote:
> Cute.  I see my multibuild.pl covered old ground.  I never looked
> at busybox.REGRESS.sh.  That file seems somewhat defective, it doesn't
> "find" as much to test as multibuild.pl, and I'm not sure why.
> multibuild.pl checked BB_DPKG_DEB (but busybox.REGRESS.sh did not),
> and found a problem, which this patch fixes.  The "cut" command for
> finding the executable file size is broken on my machine, here is
> the awk-ism that I believe is reliable.

Ahh, thx.  I hadn't even looked at the noise on the screen,
I was just letting it run till it found a bug (and it did
find quite a few of them).

> In my spare time, I can pull the size summary features into
> multibuild.pl, which looks (IMNSHO) more maintainable than the
> shell implementation.  In the long run (not for 0.49!) we should
> clearly get rid of one or the other.

I'm now running multibuild.pl (which is very, very much cleaner),
and it found another bug.  Just fixed it.

> A lot of the problems that these tools find would certainly go
> away if we turned utility.c into a "real" library, where the
> linker would take care of all those conditionals for us.
> There are certainly plenty of advantages _and_ disadvantages
> to making a _shared_ library, and the all-singing all-dancing
> future BusyBox in the sky should support both shared and
> non-shared.  The object code generated with the non-shared
> version would be nominally identical to what we have now.

Agreed.  As I was running the regression tests, I was getting
more and more convinced of this.  I have some ideas, but all
work along those lines is going to wait till after the release.

<patch applied>

 -Erik

--
Erik B. Andersen   email:  andersen at lineo.com
--This message was written using 73% post-consumer electrons--