llvm dev - Apr 2021 - Incrementally compiling LLVM

Sounds like something's going wrong for sure. How are you measuring
the time? (how much time is it taking) and what are you testing by
"partial recompilation"? Touching an ADT .h file is likely to
recompile nearly everything so might not be much better than a clean
build - but touching a .cpp file (especially a .cpp file for a single
tool, rather than a library) might be quite quick. So try timing a
full clean build (ninja -t clean, ninja clang) and then incrementally
touching just a .cpp file (eg: clang/tools/driver/driver.cpp  ) and
see how they compare

On Wed, Apr 14, 2021 at 11:21 AM Francesco Bertolaccini via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> Hi all,
> I noticed that doing a partial recompilation on Windows (I tried
> compiling with both MSVC and clang, in both cases using ninja generated
> by CMake) does not seem to be any faster than compiling from scratch.
>
> Is there any way to improve the situation? Is partial recompilation
> supported at all, or am I doing something wrong?
>
> Thanks,
> Francesco Bertolaccini
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

On 14/04/2021 21:18, David Blaikie wrote:
> Sounds like something's going wrong for sure. How are you measuring
> the time? (how much time is it taking) and what are you testing by
> "partial recompilation"? Touching an ADT .h file is likely to
> recompile nearly everything so might not be much better than a clean
> build - but touching a .cpp file (especially a .cpp file for a single
> tool, rather than a library) might be quite quick. So try timing a
> full clean build (ninja -t clean, ninja clang) and then incrementally
> touching just a .cpp file (eg: clang/tools/driver/driver.cpp  ) and
> see how they compare
I currently do not have sufficient resources to compile LLVM on my
personal machine, so I am (ab?)using GitHub Actions. My workflow is
setup such that the build artifacts are cached and restored on every
worflow run. The time is measured automatically by GitHub itself, and is
around ~2h for each run, whether from scratch or starting from the cache.

I don't generally edit .h files directly, unless they are generated by
modifying TableGen files.

The fact that someone else has successfully been able to do incremental
builds _does_ make it seem like it's a configuration issue on my part.