thoughts on coalescing libbb/ source files

[Rob Landley]

On Monday 27 March 2006 4:03 pm, Bernhard Fischer wrote:
> On Mon, Mar 27, 2006 at 01:43:33PM -0500, Rob Landley wrote:
> >On Monday 27 March 2006 7:55 am, Robert P. J. Day wrote:
> >
> >There's the strange "iterate and build multiple times" logic to produce
> > *.om
>
> 1) There is no such logic to produce *.om
> 2) Even if there was, it would be *no* different than what the current
> iterate to produce several .o does, except that the object files are
> named differently (.om instead of .o). I don't see how this is a strange
> logic, fwiw. It did just help to make the rules simpler, nothing else.
>
> >files.  And newer versions of gcc have the strange "put everything in its
> > own ELF section and eliminate dead code that way" thing the compiler can
> > do for us, although we won't be able to depend on that for another two or
> > three years and even then it means we compile stuff we don't need.  On
> > the other hand, putting together the files and iteratively producing .om
> > files means we're parsing unneeded source code repeatedly; I don't know
> > what kind of
>
> Rob, this is not true. The .om (which in fact are not there) would take the
> same amount of time it takes to build an .o . As already stated above,
> *only* the filename would differ.

Ok, so what does the *.om mean then?  I thought it meant that multiple object 
files were built from the same .c file...

Oh, hang on, this is that -PIC stuff, isn't it?

> >speed hit that has.  Presumably it's just the preprocessor operating out
> > of cache...
>
> If you care about the end-result (i.e. small size) then the best you can
> get is a recent compiler and CONFIG_BUILD_AT_ONE. Just try it out and
> compare the results, if you don't believe me.

I've tried it.  When it didn't break, and when it didn't drive my laptop to 
its knees (I have a gig of ram and a 2 mhz pentium M and my desktop became 
unusable during this), it was nice.  Of course it has no progress indicator 
whatsoever, and if it dies for any reason you have to start the entire build 
over again, and I don't know if it's going to work cross-compiling or on 
non-x86 native builds, you can't use it on older compiler versions.

Originally I was thinking that the various .a files we're already doing could 
have been built at once, perhaps grouping together subdirectories of applets.  
I really hadn't expected the all-or-nothing approach to build the entire 
project at one lump.  Even -file-at-once gives a good boost, and I don't know 
what the size difference between directory at once and whole project at once 
is.  Moot point now, I guess.

Rob
-- 
Never bet against the cheap plastic solution.