proposal to start merging some source files in libbb/

[Bernhard Fischer]

On Thu, May 18, 2006 at 01:47:07PM -0400, Paul Fox wrote:
> > >  >   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.

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.

If anyone can come up with a *good* solution for this then by all means,
go ahead.

Good implies that there is not alot of time spent in (automated) grepping
in the source like it was recently introduces in libbb. I don't mind if
this is a hardcoded list somewhere (landley had a different opinion on
that, he liked grepping through the files via sed).

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.

More details about this can be found in the archives.