proposal to start merging some source files in libbb/

[Paul Fox]

 > >but surely you can imagine a busybox binary that needs trim() but
 > >not last_char_is(), right?  that binary will be smaller today than
 > >it will be after your merge.
 > 
 > Not necessarily if we treat is properly as multi-source file.
 > 
 > I, personally, am more concerned about the fact that we build alot of
 > cruft unconditionally which is later just dropped on the floor by the
 > linker. This is not something i call clean; it just slows down building
 > and also development time needlessly.

sorry, but color me skeptical that this is a worthwhile problem.

busybox builds pretty quickly.  the second build after a "make
clean" builds _very_ quickly.  why all this worry about disk
space (too many small files) and cpu time (excessive building)? 
most developers are building defconfig or allconfig images
anyway, and so by definition are building all the "cruft".  i
doubt there would be much speedup for them.

i just timed a build of my current production busybox config. 
the whole thing after a clean took 1m15s.  if i clean out libbb
and run it again, it takes 20s.  so even if you cut libbb time in
half you'd only speed up my clean build by 10s out of 75.  big
deal.  and non-clean builds would be unaffected.

 > What would be needed is to create a list for all selected applets,
 > iterate over them to collect a list of functions which are exported via
 > libbb.h and use *that* list after $(sort ) as stuff to actually build.

and the added complexity will probably require GNU make 4.30 to
support it.  i'm a big fan of KISS.  on-demand linking has solved
this problem for many years.

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