proposal to start merging some source files in libbb/

[Rob Landley]

On Thursday 18 May 2006 1:16 pm, Robert P. J. Day wrote:
>   just before i head for the gym, a repeat of a thought i had a couple
> months back.  it seems that there's just too many trivial source files
> in libbb/, and some of them could be merged and be even more
> meaningful afterwards.
>
>   as a trivial example,
>
> 	create_icmp_socket.c
> 	create_icmp6_socket.c

Traditionally the compiler could only include or exclude things at the .o 
level, so if a .o file had some used functions and some unused functions, it 
would have to include the whole thing.  The compiler didn't know what was and 
wasn't used, and the linker couldn't cherry-pick below the object file level.  
So we broke up the .o functions as small as possible to avoid including 
unused functions.

We have the ability ability to produce multiple .o files from a single .c 
file, and we've recently made it easier to use.  More cleanup in that 
direction is a good thing (followup to svn 15074).

Binutils has also recently developed the ability to do something vaguely sane, 
with the --gc-sections option circa binutils 2.17 and up.  That's too new to 
rely on it, but having that be a CHECK_LD option (disabled by 
DEBUG_PESSIMIZE) would be a good thing, and perhaps we can rely on it and 
remove our own workarounds for its absence in around 3 years.

>   as another example, how about xgethostbyname*.c?  it's hard to
> defend a separate source file for a 5-line function, so do the same
> thing there.

I personally find the most annoying example to be libbb/mtab_file.c.

I'm all for cleaning this up, just be aware of the issues and check the binary 
size as you go...

Rob
-- 
Never bet against the cheap plastic solution.