[BusyBox] Makefile and distcc

Rob Landley rob at landley.net
Tue May 24 05:22:36 UTC 2005


On Saturday 21 May 2005 04:37 pm, busybox at rich-paul.net wrote:
> Hey, all, while attempting to compile busybox with distcc, I've noticed
> some makefile oddities that seem to be slowing down the process:

Improving the busybox makefile is a longstanding to-do item here.  If you want 
to take a whack at it, I'm all for it.  (I'm not personally at all good with 
makefiles, though.)

> Two questions:
> 1)	I've developed an applet called xcat which reads the magic from a
> 	compressed file, and based on the magic, acts like either zcat, bzcat,
> 	or uncompress, or plain old cat (if the magic isn't magic).  But
> 	since most of busybox is made up of stripped down versions of
> 	standard unix programs and there is no standard unix xcat, I'm not
> 	sure if you'd be interested in this applet.

We'd probably be interested in seeing the patch, at least.

> 2)	In the process of writing the applet, I was compiling busybox with
> 	no other applets enabled, and was somewhat slowed down by the fact
> 	that all the files in libbb.a were compiled, even though very few of
> 	them were used.

Sucks, doesn't it?

I've got some sample shell scripts (_not_ makefile bits, but just a shell 
script that does a bunch of varied gcc invocations) to build a couple dozen 
of the busybox applets as standalone executables.  And the only way I could 
get it to work was build libbb.a with "make allyesconfig" and then link 
against libbb.a from my build script.

That directory is also a big part of the reason you have to do a "make clean" 
if you call "make menuconfig" after building a different config and want 
consistent behavior.  (If you change the options to an applet that has 
sub-options, like "find", and rebuild, it doesn't actually bother to 
recompile any *.c files.)

The busybox makefile is a mess, really.  And not all the problems are 
trivially solved, either...

> 	I played with using a perl script and nm in order to determine what
> 	functions are exported and required by the various .o modules, and
> 	am curious as to whether the developers would be interested in
> 	seeing a patch which would optimize the build by adding a target,
> 	perhaps called bindep, which would build all the objects, collect
> 	their dependency information, and save it to disk in the form of
> 	makefile fragments, which could be included in the distribution tar.

You'd have to ask Erik.  Personally I think adding perl to the build is a cure 
worse than the disease, but that's just me. :)

Rationalizing the dependencies is good, though.  (And having perl detect the 
dependencies and tell us where we got them wrong makes sense, as long as you 
never need perl to actually build the thing.)

Rob



More information about the busybox mailing list