Weddington, Eric wrote:
-----Original Message----- From:
avr-libc-dev-bounces+eweddington=cso.atmel....@nongnu.org
[mailto:avr-libc-dev-bounces+eweddington=cso.atmel....@nongnu. org]
On Behalf Of David Brown Sent: Tuesday, December 23, 2008 9:24 AM
To: avr-libc-dev@nongnu.org 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
_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
