proposal to start merging some source files in libbb/

[Paul Fox]

 > >  >   as a trivial example,
 > >  >
 > >  > 	create_icmp_socket.c
 > >  > 	create_icmp6_socket.c
 > >  >
 > >  > those files each define a single function, and have common includes,
 > >
 > > is it not it true that one can build a busybox that only needs one
 > > of these?  if so, won't combining them in a single .o cause them
 > > both to be pulled in all the time?
 > 
 > if you check those two files above, you'll notice first that one is
 > only *conditionally* included -- that conditional inclusion would be
 > carried over to the new file so you'd get exactly the same effect.

in the general case, both functions would need to be conditionally
compiled.  you're assuming that all the conditionals are correct
and complete.

 > also, i was careful to choose only examples that are part of the
 > "LIBBB-y" variable from Makefile.in, so the end result should be
 > *exactly* the same.
 > 
 > i've tested this and it works just fine.

by this logic we could put all of libb/*.c into a single file
and we'd still get the minimal subset of routines we need, in
every case.  this clearly isn't true.

i think you're confusing compile-time selection (ifdefs, and the
LIBBB-? variables) with link-time selection -- whether my configured
set of busybox applets actually needs to pull a given .o out of
the library or not, even if that .o was indeed built.

 > BTW, my longer-term thought is to do a fair bit more merging to
 > collect related functions into the same single source file.  i can
 > imagine something like
 > 
 > libbb/string_ops.c
 > 	trim()
 > 	chomp()
 > 	last_char_is()
 > 	bb_skip_whitespace()
 > 
 > and so on.  at the moment, each of those functions sucks up its own
 > source file, for no obvious reason.

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.

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