[avr-libc-dev] Re: Add lib per devide.

[David Brown]

Weddington, Eric wrote:
> > -----Original Message----- From: 
> > address@hidden 
> > [mailto:address@hidden org]
> > On Behalf Of David Brown Sent: Tuesday, December 23, 2008 9:24 AM 
> > To: address@hidden Subject: [avr-libc-dev] Re: Add lib per
> > devide.
> >
> > Have you tried using ccache?  I haven't used it for compiling 
> > avrgcc or avr-libc (I haven't recompiled these myself for ages -
> > the winavr package is too good!), but I've used it for other 
> > compilations on both cygwin and linux.
>
> You have to consider the type of project that avr-libc is. Avr-libc
> is a library project, with many small modules that are written in
> hand-optimized assembly, and built for many, many targets.
>
> From looking at the website of ccache, it seems like it is a
> preprocessor cache. There is very little preprocessing done on these
> small assembly files. So I really don't see that ccache would be that
> useful.

ccache certainly won't help with assembly files.  Basically, ccache does 
the pre-processing (#includes, #macros, etc.) and forms a hash from the 
pre-processed file, the C compiler binary, and the command line options. 
 If it has seen this hash before, it returns the object file.  If not, 
it does the compilation and stores the resulting object file for later 
use.  So if you often find you are re-compiling the same code, it can be 
a big win.  But if you are using assembly files, or if the files, the 
options, or the compiler, actually change often, then it is of little use.

> However, because this library is built for many targets (a lot more
> so, if it were per device), the hierarchy of dependencies is not deep
> but it is very wide, i.e. a lot of independent targets. When you have
> a lot of independent targets, they can be built in parallel using
> 'make -j'. This is the reason for the large time savings in building
> avr-libc.
>
> If we built a library per device in avr-libc, I really don't worry
> about how much time it takes. However, we should then have libgcc
> built per device. Unfortunately, building gcc in parallel using 'make
> -j' is problematic so it would take a lot of time building libgcc per
> device.
>
> Eric

Certainly "make -j" can be a big win on modern machines with multiple 
processors (and for the really ambitious, you can use multiple machines 
and distcc - although I've not tried it myself).

Would you not still only need to build *one* version of gcc, even though 
you needed libgcc?

Perhaps it would be possible to combine the efforts - avr-libc sounds an 
ideal candidate for "make -j", while using ccache for gcc would let you 
combine identical compilations.

mvh.,

David