[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Brown
Subject: [avr-libc-dev] Re: Add lib per devide.
Date: Wed, 24 Dec 2008 02:19:13 +0100
User-agent: Thunderbird (Windows/20081105)

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

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

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

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


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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]