[PATCH] [DOCS] How to Add a Builder

[Alp Toker]

On 14/11/2013 05:43, Reid Kleckner wrote:
> IMO ccache is unnecessary if you use cmake+ninja.  They actually track
> header dependencies well, so as long as you don't clean your build
> directory, you'll have fast, correct incremental builds.  ccache won't
> save much in that situation because the preprocessed source will
> actually be different.

A couple of notes on this:

ninja tracks timestamps and deps very well but ccache normalizes the
source contents to avoid rebuilds in many more cases like code shuffles
and comment edits. Most of all it detects irrelevant changes in the
include chain, so it's certainly worthwhile having the two together
regardless of whether you're rebuilding from scratch.

On the other hand, cmake has a bug that means incremental builds are
flawed, at least in builds with clang but probably also affecting llvm core.

I've been posting updates on this to cfe-dev and working with the CMake
guys to fix the problem upstream:

  http://www.cmake.org/Bug/view.php?id=14546

The failure mode is very confusing when configuration values stick
around from previous revisions -- there've been a few heisenbug threads
on the list where builds picked up old settings, old headers etc. and
the time wasted debugging failures outweighs any benefit from
incremental building until this bug is fixed.

So until then, it's a better idea to rebuild from scratch on each
iteration if using CMake.

Alp.



>
>
> On Wed, Nov 13, 2013 at 9:12 PM, Mikael Lyngvig <mikael at lyngvig.org
> <mailto:mikael at lyngvig.org>> wrote:
>
>     Hi,
>
>     The patch basically tells that ccache is very usable for low-end
>     Linux systems and briefly how to get going using ccache (one
>     special option is needed, thanks to Dimitri Gribenko, for sharing
>     this).  
>
>     On my ARMv7 a repeat clean build takes less than 1/3rd the time of
>     the initial clean build.  So it is definitely something that the
>     slow builders can benefit from.  A build time of 36 minutes was
>     reduced to approximately 11.5 minutes.
>
>     I suspect it might better be put in the GettingStarted document,
>     but I need feedback on this.
>
>     If anybody dislikes the idea of putting this patch in the LLVM
>     documentation, then please think of the fact that LLVM benefits
>     greatly from the builders doing their job as fast as at all possible.
>
>
>     -- Mikael
>
>
>     _______________________________________________
>     llvm-commits mailing list
>     llvm-commits at cs.uiuc.edu <mailto:llvm-commits at cs.uiuc.edu>
>     http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-- 
http://www.nuanti.com
the browser experts