thoughts on coalescing libbb/ source files

[Paul Fox]

 >   from the libbb/ README file, i can see the history of libbb:
 > 
 > "libbb is BusyBox's utility library.  All of this stuff used to be
 > stuffed into a single file named utility.c.  When I split utility.c to
 > create libbb, ..."
 > 
 >   fair enough but it seems that the breaking into separate source
 > files went a little too far in the other direction.  in many cases,
 > there are *closely* related routines that are placed in separate
 > source files for no obvious reason that i can see, where it would make
 > more sense to group tightly-related routines in a single source file.

i assume the goal was to make the .o files as small as possible,
so that applet needing just one routine from a file would be
as small as possible as well.  that is, if you put all the
perror_xxx() routines in one file, then my binary gets them all,
even if i only use one.  obviously the more applets that are
build into a single executable, the less a factor this
would be.

 > 
 >   a perfect example would be all of the *error*.c files (defining
 > functions like bb_error_msg(), bb_error_msg_and_die(),
 > bb_herror_msg(), bb_hrror_msg_and_die(), ... and on and on.)  each of
 > those functions is only a few lines long but is in its own source
 > file, requiring the duplication of the copyright info and inclusion of
 > header files and "end code" stuff.
 > 
 >   it would seem to make more sense to pack all these error routines
 > into a single source file (called "bb_error.c"?) so one could, if one
 > wanted, peruse all of those related routines by scrolling through a
 > single file, no?  at the very least, i don't see any immediate
 > drawback to it but maybe i'm just not looking closely enough.

it does seem as if some sort of multi-source technique (i.e., one
source file, with preprocessor controls to allow rendering many
different small objects) could be useful.

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