[cfe-dev] cfe-dev Digest, Vol 46, Issue 91

[Óscar Fuentes]

Hello Yuri. Sorry for the delay.

Yuri Gribov <tetra2005 at googlemail.com> writes:

>>> I think we could simply mention it somewhere in the docs.
>> Maybe on http://www.llvm.org/docs/CMake.html#msvc ?
>
> What about http://llvm.org/docs/FAQ.html#build ? I think this problem
> is not VS specific (but I do not have a Linux at hand to check it).

It is not a problem on Linux. Process creation is so fast that the extra
cmake instances add virtually nothing to the build and there is only one
build configuration per build directory.

>>>> Digging this problem took quite some time and there is no need for
>>>> other people to repeat this process.
>>> Patches welcome.
>> Got it, I will try to send something today. If not we'll have to wait
>> 2 weeks until I get back from my vacation)
>
> Oscar,
>
> Could you verify (and apply if it's more or less correct) the attached
> patch for docs/FAQ.html?

Approval for adding such long chunk of text to FAQ.html must be granted
by somebody else (Chris?). CMake.html is under my jurisdiction, though.

Some comments follow.

> Index: docs/FAQ.html
> ===================================================================
> --- docs/FAQ.html	(revision 130612)
> +++ docs/FAQ.html	(working copy)
> @@ -77,6 +77,9 @@
>  
>      <li><a href="#srcdir-objdir">When I compile LLVM-GCC with srcdir == objdir,
>          it fails. Why?</a></li>
> +
> +    <li><a href="#vsalwaysbuild">Why Visual Studio rebuilds a lot of stuff on every run
> +        even if I don't change anything?</a></li>
>    </ol></li>
>  
>    <li><a href="#felangs">Source Languages</a>
> @@ -448,6 +451,41 @@
>  <p>We regret the inconvenience.</p>
>  </div>
>  
> +<div class="question">
> +<p><a name="vsalwaysbuild">Why Visual Studio rebuilds a lot of stuff on every run
> +   even if I don't change anything?</a></p>
> +</div>
> +
> +<div class="answer">
> +<p>The most probable cause are custom build rules for tablegen files.
> +Whenever the tablegen executable is rebuilt, all the corresponding tablegen
> +files have to be rebuilt. It turns out that most of the time these files do not
> +change so to speed up the build we only write the generated code to
> +target files if it's actually different (we use CMake's copy_if_different command for this).
> +This allows us to avoid an unnecessary massive rebuild of the whole codebase.
> +An unfortunate side effect is that the timestamps of destination files remain unchanged
> +which forces Visual Studio to try to (unsuccessfully) build them (and all dependent projects)
> +on every subsequent compilation.</p>
> +
> +<p>In particular this problem tends to arise when you build several configurations of LLVM
> +in one directiry. E.g. if you try to build Release after building Debug you will
> +build a new (Release) tablegen executable which will force all tablegen files to be rebuilt.
> +The generated code will be unchanged and will not be copied to target files thus causing
> +the problem described above.</p>
> +
> +<p>If this is an issue you could try one of the following:
> +  <ul>
> +  <li>use separate directories for different build configurations
> +  <li>completely rebuild your solution
> +  <li>preprocess cmake-generated vcproj files to always write generated code
> +  to target files even if it did not change; if you have Cygwin you can use this script:
> +  </ul>
> +</p>
> +<pre class="doc_code">
> +% find $LLVM_OBJ_DIR -name '*.vcproj' | xargs sed -i -e 's/copy_if_different/copy/g'
> +</pre>
> +</div>

This last option is not a good advice. copy_if_different may appear
elsewhere anytime on the cmake sources and replacing it with `copy' may
cause problems.

There is another possibility for removing the part of the problem caused
by building multiple configurations on the same directory: set the
LLVM_TABLEGEN cmake variable to certain tblgen.exe program. This way you
avoid the problem caused by having multiple configurations because all
configurations will use the same tblgen. As an extra bonus, if that
tblgen executable belongs to a Release build, your Debug builds will be
faster.

This sequence of commands should do the trick (untested):

# Configure:

cmake -DLLVM_TABLEGEN=/your-llvm-build-root/bin/Release/tblgen.exe path/to/llvm/sources

# Build the Release configuration, or just tblgen.exe in Release mode:

cmake --build . --target tblgen --config Release

# Now we can build the Debug configuration using the previosly built
# tblgen.exe:

cmake --build . --config Debug