Fix compilation issue in VS2017 with Clang-tablegen and LLVM-tablegen

[aganea]

Summary

When compiling Clang with Visual Studio 2017 as a compiler, I randomly see the following errors:

7>C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\VC\VCTargets\Microsoft.CppBuild.targets(321,5): error MSB3491: Impossible d'écrire des lignes dans le fichier "LLVMDemangle.dir\Release\LLVMDemangle.tlog\LLVMDemangle.lastbuildstate". Le processus ne peut pas accéder au fichier 'F:\svn\build\NATIVE\lib\Demangle\LLVMDemangle.dir\Release\LLVMDemangle.tlog\LLVMDemangle.lastbuildstate', car il est en cours d'utilisation par un autre processus. [F:\svn\build\NATIVE\lib\Demangle\LLVMDemangle.vcxproj]
7>Génération du projet "F:\svn\build\NATIVE\lib\Demangle\LLVMDemangle.vcxproj" terminée (cibles par défaut) -- ÉCHEC.

This says basically that some target files are locked by another process.
This is caused by Clang-tablegen and LLVM-tablegen explicitly compiling at the same time, through a custom build command:

"C:\Program Files\CMake\bin\cmake.exe" --build F:/svn/build/NATIVE --target clang-tblgen --config Release

and:

"C:\Program Files\CMake\bin\cmake.exe" --build F:/svn/build/NATIVE --target llvm-tblgen --config Release

...thus compiling dependencies at the same time, in the same target folders.

This workaround simply makes Clang-tablegen depend on LLVM-tablegen which prevents this issue. Unless you can suggest a better way?

---

Full log:

6>------ Build started: Project: LLVM-tablegen-host, Configuration: Debug x64 ------
7>------ Build started: Project: CLANG-tablegen-host, Configuration: Debug x64 ------
6>Building native TableGen...
7>Building native TableGen...
6>Microsoft (R) Build Engine version 15.8.169+g1ccb72aefa pour .NET Framework
6>Copyright (C) Microsoft Corporation. Tous droits réservés.
6>
7>Microsoft (R) Build Engine version 15.8.169+g1ccb72aefa pour .NET Framework
7>Copyright (C) Microsoft Corporation. Tous droits réservés.
7>
6>La génération a démarré 2018-11-05 17:39:04.
7>La génération a démarré 2018-11-05 17:39:04.
6>Projet "F:\svn\build\NATIVE\utils\TableGen\llvm-tblgen.vcxproj" sur le noud 1 (cibles par défaut).
6>Le projet "F:\svn\build\NATIVE\utils\TableGen\llvm-tblgen.vcxproj" (1) génère "F:\svn\build\NATIVE\ZERO_CHECK.vcxproj" (2) sur le noud 1 (cibles par défaut).
7>Projet "F:\svn\build\NATIVE\tools\clang\utils\TableGen\clang-tblgen.vcxproj" sur le noud 1 (cibles par défaut).
7>Le projet "F:\svn\build\NATIVE\tools\clang\utils\TableGen\clang-tblgen.vcxproj" (1) génère "F:\svn\build\NATIVE\ZERO_CHECK.vcxproj" (2) sur le noud 1 (cibles par défaut).
6>InitializeBuildStatus:
6>  Création de "x64\Release\ZERO_CHECK\ZERO_CHECK.tlog\unsuccessfulbuild", car "AlwaysCreate" a été spécifié.
7>InitializeBuildStatus:
7>  Mise à jour de l'horodatage "x64\Release\ZERO_CHECK\ZERO_CHECK.tlog\unsuccessfulbuild".
6>CustomBuild:
6>  Toutes les sorties sont à jour.
7>CustomBuild:
7>  Toutes les sorties sont à jour.
7>FinalizeBuildStatus:
7>  Suppression du fichier "x64\Release\ZERO_CHECK\ZERO_CHECK.tlog\unsuccessfulbuild".
7>  Mise à jour de l'horodatage "x64\Release\ZERO_CHECK\ZERO_CHECK.tlog\ZERO_CHECK.lastbuildstate".
7>Génération du projet "F:\svn\build\NATIVE\ZERO_CHECK.vcxproj" terminée (cibles par défaut).
6>FinalizeBuildStatus:
6>  Suppression du fichier "x64\Release\ZERO_CHECK\ZERO_CHECK.tlog\unsuccessfulbuild".
6>  Mise à jour de l'horodatage "x64\Release\ZERO_CHECK\ZERO_CHECK.tlog\ZERO_CHECK.lastbuildstate".
6>Génération du projet "F:\svn\build\NATIVE\ZERO_CHECK.vcxproj" terminée (cibles par défaut).
6>Le projet "F:\svn\build\NATIVE\utils\TableGen\llvm-tblgen.vcxproj" (1) génère "F:\svn\build\NATIVE\lib\Demangle\LLVMDemangle.vcxproj" (3) sur le noud 1 (cibles par défaut).
6>InitializeBuildStatus:
6>  Création de "LLVMDemangle.dir\Release\LLVMDemangle.tlog\unsuccessfulbuild", car "AlwaysCreate" a été spécifié.
6>CustomBuild:
6>  Toutes les sorties sont à jour.
7>Le projet "F:\svn\build\NATIVE\tools\clang\utils\TableGen\clang-tblgen.vcxproj" (1) génère "F:\svn\build\NATIVE\lib\Demangle\LLVMDemangle.vcxproj" (3) sur le noud 1 (cibles par défaut).
7>C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\VC\VCTargets\Microsoft.CppBuild.targets(321,5): error MSB3491: Impossible d'écrire des lignes dans le fichier "LLVMDemangle.dir\Release\LLVMDemangle.tlog\LLVMDemangle.lastbuildstate". Le processus ne peut pas accéder au fichier 'F:\svn\build\NATIVE\lib\Demangle\LLVMDemangle.dir\Release\LLVMDemangle.tlog\LLVMDemangle.lastbuildstate', car il est en cours d'utilisation par un autre processus. [F:\svn\build\NATIVE\lib\Demangle\LLVMDemangle.vcxproj]
7>Génération du projet "F:\svn\build\NATIVE\lib\Demangle\LLVMDemangle.vcxproj" terminée (cibles par défaut) -- ÉCHEC.
6>ClCompile:
6>  Toutes les sorties sont à jour.
7>Le projet "F:\svn\build\NATIVE\tools\clang\utils\TableGen\clang-tblgen.vcxproj" (1) génère "F:\svn\build\NATIVE\lib\Support\LLVMSupport.vcxproj" (4) sur le noud 1 (cibles par défaut).
7>InitializeBuildStatus:
7>  Création de "LLVMSupport.dir\Release\LLVMSupport.tlog\unsuccessfulbuild", car "AlwaysCreate" a été spécifié.
7>CustomBuild:
7>  Toutes les sorties sont à jour.
7>ClCompile:
7>  Toutes les sorties sont à jour.
6>Lib:
6>  Toutes les sorties sont à jour.
6>  LLVMDemangle.vcxproj -> F:\svn\build\NATIVE\Release\lib\LLVMDemangle.lib
6>FinalizeBuildStatus:
6>  Suppression du fichier "LLVMDemangle.dir\Release\LLVMDemangle.tlog\unsuccessfulbuild".
6>  Mise à jour de l'horodatage "LLVMDemangle.dir\Release\LLVMDemangle.tlog\LLVMDemangle.lastbuildstate".
6>Génération du projet "F:\svn\build\NATIVE\lib\Demangle\LLVMDemangle.vcxproj" terminée (cibles par défaut).
6>Le projet "F:\svn\build\NATIVE\utils\TableGen\llvm-tblgen.vcxproj" (1) génère "F:\svn\build\NATIVE\lib\Support\LLVMSupport.vcxproj" (4) sur le noud 1 (cibles par défaut).
6>InitializeBuildStatus:
6>  Mise à jour de l'horodatage "LLVMSupport.dir\Release\LLVMSupport.tlog\unsuccessfulbuild".
6>CustomBuild:
6>  Toutes les sorties sont à jour.
7>  Toutes les sorties sont à jour.
7>Lib:
7>  Toutes les sorties sont à jour.
7>  LLVMSupport.vcxproj -> F:\svn\build\NATIVE\Release\lib\LLVMSupport.lib
7>FinalizeBuildStatus:
7>  Suppression du fichier "LLVMSupport.dir\Release\LLVMSupport.tlog\unsuccessfulbuild".
7>  Mise à jour de l'horodatage "LLVMSupport.dir\Release\LLVMSupport.tlog\LLVMSupport.lastbuildstate".
7>Génération du projet "F:\svn\build\NATIVE\lib\Support\LLVMSupport.vcxproj" terminée (cibles par défaut).
6>ClCompile:
6>  Toutes les sorties sont à jour.
7>Le projet "F:\svn\build\NATIVE\tools\clang\utils\TableGen\clang-tblgen.vcxproj" (1) génère "F:\svn\build\NATIVE\lib\TableGen\LLVMTableGen.vcxproj" (5) sur le noud 1 (cibles par défaut).
7>InitializeBuildStatus:
7>  Création de "LLVMTableGen.dir\Release\LLVMTableGen.tlog\unsuccessfulbuild", car "AlwaysCreate" a été spécifié.
7>CustomBuild:
7>  Toutes les sorties sont à jour.
7>ClCompile:
7>  Toutes les sorties sont à jour.
7>Lib:
7>  Toutes les sorties sont à jour.
7>  LLVMTableGen.vcxproj -> F:\svn\build\NATIVE\Release\lib\LLVMTableGen.lib
7>FinalizeBuildStatus:
7>  Suppression du fichier "LLVMTableGen.dir\Release\LLVMTableGen.tlog\unsuccessfulbuild".
7>  Mise à jour de l'horodatage "LLVMTableGen.dir\Release\LLVMTableGen.tlog\LLVMTableGen.lastbuildstate".
7>Génération du projet "F:\svn\build\NATIVE\lib\TableGen\LLVMTableGen.vcxproj" terminée (cibles par défaut).
6>  Toutes les sorties sont à jour.
6>Lib:
6>  Toutes les sorties sont à jour.
6>  LLVMSupport.vcxproj -> F:\svn\build\NATIVE\Release\lib\LLVMSupport.lib
6>FinalizeBuildStatus:
6>  Mise à jour de l'horodatage "LLVMSupport.dir\Release\LLVMSupport.tlog\LLVMSupport.lastbuildstate".
6>Génération du projet "F:\svn\build\NATIVE\lib\Support\LLVMSupport.vcxproj" terminée (cibles par défaut).
6>Le projet "F:\svn\build\NATIVE\utils\TableGen\llvm-tblgen.vcxproj" (1) génère "F:\svn\build\NATIVE\lib\TableGen\LLVMTableGen.vcxproj" (5) sur le noud 1 (cibles par défaut).
6>InitializeBuildStatus:
6>  Création de "LLVMTableGen.dir\Release\LLVMTableGen.tlog\unsuccessfulbuild", car "AlwaysCreate" a été spécifié.
6>CustomBuild:
6>  Toutes les sorties sont à jour.
6>ClCompile:
6>  Toutes les sorties sont à jour.
6>Lib:
6>  Toutes les sorties sont à jour.
6>  LLVMTableGen.vcxproj -> F:\svn\build\NATIVE\Release\lib\LLVMTableGen.lib
6>FinalizeBuildStatus:
6>  Suppression du fichier "LLVMTableGen.dir\Release\LLVMTableGen.tlog\unsuccessfulbuild".
6>  Mise à jour de l'horodatage "LLVMTableGen.dir\Release\LLVMTableGen.tlog\LLVMTableGen.lastbuildstate".
6>Génération du projet "F:\svn\build\NATIVE\lib\TableGen\LLVMTableGen.vcxproj" terminée (cibles par défaut).
7>Le projet "F:\svn\build\NATIVE\tools\clang\utils\TableGen\clang-tblgen.vcxproj" (1) génère "F:\svn\build\NATIVE\tools\clang\utils\TableGen\obj.clang-tblgen.vcxproj" (6) sur le noud 1 (cibles par défaut).
7>InitializeBuildStatus:
7>  Création de "obj.clang-tblgen.dir\Release\obj.clang-tblgen.tlog\unsuccessfulbuild", car "AlwaysCreate" a été spécifié.
7>CustomBuild:
7>  Toutes les sorties sont à jour.
7>ClCompile:
7>  Toutes les sorties sont à jour.
7>Lib:
7>  Toutes les sorties sont à jour.
7>  obj.clang-tblgen.vcxproj -> F:\svn\build\NATIVE\tools\clang\utils\TableGen\obj.clang-tblgen.dir\Release\obj.clang-tblgen.lib
7>FinalizeBuildStatus:
7>  Suppression du fichier "obj.clang-tblgen.dir\Release\obj.clang-tblgen.tlog\unsuccessfulbuild".
7>  Mise à jour de l'horodatage "obj.clang-tblgen.dir\Release\obj.clang-tblgen.tlog\obj.clang-tblgen.lastbuildstate".
7>Génération du projet "F:\svn\build\NATIVE\tools\clang\utils\TableGen\obj.clang-tblgen.vcxproj" terminée (cibles par défaut).
7>Génération du projet "F:\svn\build\NATIVE\tools\clang\utils\TableGen\clang-tblgen.vcxproj" terminée (cibles par défaut) -- ÉCHEC.
7>
7>ÉCHEC de la build.
7>
7>"F:\svn\build\NATIVE\tools\clang\utils\TableGen\clang-tblgen.vcxproj" (cible par défaut) (1) ->
7>"F:\svn\build\NATIVE\lib\Demangle\LLVMDemangle.vcxproj" (cible par défaut) (3) ->
7>(InitializeBuildStatus cible) ->
7>C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\VC\VCTargets\Microsoft.CppBuild.targets(321,5): error MSB3491: Impossible d'écrire des lignes dans le fichier "LLVMDemangle.dir\Release\LLVMDemangle.tlog\LLVMDemangle.lastbuildstate". Le processus ne peut pas accéder au fichier 'F:\svn\build\NATIVE\lib\Demangle\LLVMDemangle.dir\Release\LLVMDemangle.tlog\LLVMDemangle.lastbuildstate', car il est en cours d'utilisation par un autre processus. [F:\svn\build\NATIVE\lib\Demangle\LLVMDemangle.vcxproj]
7>
7>    0 Avertissement(s)
7>    1 Erreur(s)
7>
7>Temps écoulé 00:00:00.79
7>Done building project "CLANG-tablegen-host.vcxproj" -- FAILED.

[nhaehnle]

Interesting. Thanks for digging into buildsystem stuff!

cmake/modules/TableGen.cmake

174–176

Seems to me that this should logically rather something like:

if (NOT ${project} STREQUAL LLVM)
  add_dependencies(${project}-tablegen-host LLVM-tablegen-host)
endif()

[aganea]

Updated with Nicolai's suggestion.

[zturner]

Unfortunately I can't read your output log, but I'm a little bit concerned that we're making a change to the dependency graph for what seems to be a problem only with the Visual Studio generator (or, at least, nobody has ever observed this problem with any other build system). Is the dependency actually correct?

[aganea]

In D54153#1288814, @zturner wrote:

Unfortunately I can't read your output log, but I'm a little bit concerned that we're making a change to the dependency graph for what seems to be a problem only with the Visual Studio generator (or, at least, nobody has ever observed this problem with any other build system). Is the dependency actually correct?

The issue is that XXX-tablegen-host .vcxprojects are explicitly calling cmake --build, thus not going through MSBuild's dependency graph. It looks like the Ninja generator doesn't do that.
I can make this hack specific to the "Visual Studios" generators.

[aganea]

To give more insight: this part of script is called only if LLVM_USE_HOST_TOOLS is set, such as:

if(CMAKE_CROSSCOMPILING OR (LLVM_OPTIMIZED_TABLEGEN AND (LLVM_ENABLE_ASSERTIONS OR CMAKE_CONFIGURATION_TYPES)))
  set(LLVM_USE_HOST_TOOLS ON)
endif()

In my case, I've enabled LLVM_OPTIMIZED_TABLEGEN because it's faster to build. When using a "Visual Studio XX" generator CMAKE_CONFIGURATION_TYPES is also set. However, when using "Ninja", cmake is using CMAKE_BUILD_TYPE instead, and makes CMAKE_CONFIGURATION_TYPES an empty value.

Looking how multi-configuration are determined in cmake, it looks like this issue would only affect Visual Studio and XCode generators.
I've constrained this patch to Visual Studio generators for now.

[rnk]

In D54153#1288824, @aganea wrote:

The issue is that XXX-tablegen-host .vcxprojects are explicitly calling cmake --build, thus not going through MSBuild's dependency graph. It looks like the Ninja generator doesn't do that.

Really? I thought it did... The main reason I don't use the "optimized tablegen" build configuration is because it doesn't keep everything in a single ninja build file. I just always compile with optimization, asserts, and debug info enabled.

I can make this hack specific to the "Visual Studios" generators.

It seems like it would be a problem in all generators to me. It's just that MSBuild is the only one with a locking mechanism that detects this race.

[nhaehnle]

In D54153#1288936, @rnk wrote:

In D54153#1288824, @aganea wrote:

The issue is that XXX-tablegen-host .vcxprojects are explicitly calling cmake --build, thus not going through MSBuild's dependency graph. It looks like the Ninja generator doesn't do that.

Really? I thought it did... The main reason I don't use the "optimized tablegen" build configuration is because it doesn't keep everything in a single ninja build file. I just always compile with optimization, asserts, and debug info enabled.

That's right. I just double-checked, and in my debug build setup I do have separate "build.ninja" files which I don't have for my optimized build. So while I'm no expert in LLVM's build system, it does like this change shouldn't be gated by the generator type.

[aganea]

I managed to reproduce the issue with Ninja as well. It happens rarely, 1 out 5 runs.

aganea@PC MINGW64 /f/svn/llvm
$ rmdir -rf build
$ cmake -G Ninja f:/svn/llvm -DCMAKE_BUILD_TYPE=Debug -DLLVM_OPTIMIZED_TABLEGEN=true -DLLVM_EXTERNAL_CLANG_SOURCE_DIR=f:/svn/clang -DLLVM_EXTERNAL_LLD_SOURCE_DIR=f:/svn/lld -DLLVM_TOOL_LLD_BUILD=true -DLLVM_TOOL_CLANG_BUILD=true -DLLVM_ENABLE_LLD=true -DCMAKE_C_COMPILER="c:/Program Files/LLVM/bin/clang-cl.exe" -DCMAKE_CXX_COMPILER="c:/Program Files/LLVM/bin/clang-cl.exe"
[...]
[576/3829] Configuring NATIVE LLVM...
FAILED: NATIVE/CMakeCache.txt
cmd.exe /C "cd /D F:\svn\buildninja\NATIVE && "C:\Program Files\CMake\bin\cmake.exe" -G Ninja -DCMAKE_MAKE_PROGRAM="C:/PROGRA~2/MIB055~1/2017/PROFES~1/Common7/IDE/COMMON~1/MICROS~1/CMake/Ninja/ninja.exe" "-DCMAKE_C_COMPILER=c:/Program Files/LLVM/bin/clang-cl.exe" "-DCMAKE_CXX_COMPILER=c:/Program Files/LLVM/bin/clang-cl.exe" F:/svn/llvm -DLLVM_TARGET_IS_CROSSCOMPILE_HOST=TRUE -DLLVM_TARGETS_TO_BUILD="AArch64;AMDGPU;ARM;BPF;Hexagon;Lanai;Mips;MSP430;NVPTX;PowerPC;Sparc;SystemZ;WebAssembly;X86;XCore" -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD="" -DLLVM_DEFAULT_TARGET_TRIPLE="x86_64-pc-windows-msvc" -DLLVM_TARGET_ARCH="host" -DCMAKE_BUILD_TYPE=Release -DLLVM_USE_LINKER=lld -DLLVM_EXTERNAL_CLANG_SOURCE_DIR=f:/svn/clang"
-- The C compiler identification is Clang 7.0.0
-- The CXX compiler identification is Clang 7.0.0
-- The ASM compiler identification is Clang
[...]
-- Looking for __chkstk
-- Looking for __chkstk - found
-- Looking for __chkstk_ms
CMake Error: Unable to open check cache file for write. F:/svn/buildninja/NATIVE/CMakeFiles/CMakeTmp/CMakeFiles/cmake.check_cache
CMake Error at C:/Program Files/CMake/share/cmake-3.12/Modules/CheckFunctionExists.cmake:72 (try_compile):
  Failed to configure test project build system.
Call Stack (most recent call first):
  cmake/config-ix.cmake:222 (check_function_exists)
  CMakeLists.txt:578 (include)


-- Configuring incomplete, errors occurred!
See also "F:/svn/buildninja/NATIVE/CMakeFiles/CMakeOutput.log".
See also "F:/svn/buildninja/NATIVE/CMakeFiles/CMakeError.log".
[577/3829] Linking CXX shared library bin\OptRemarks.dll
link.exe: warning: ignoring unknown argument: -fuse-ld=lld
link.exe: warning: ignoring unknown argument: -fuse-ld=lld
[581/3829] Linking CXX executable bin\llvm-undname.exe
link.exe: warning: ignoring unknown argument: -fuse-ld=lld
link.exe: warning: ignoring unknown argument: -fuse-ld=lld
[589/3829] Building CXX object utils\benchmark\src\CMakeFiles\benchmark.dir\sysinfo.cc.obj
F:\svn\llvm\utils\benchmark\src\sysinfo.cc(349,7):  warning: default label in switch which covers all enumeration values [-Wcovered-switch-default]
      default:
      ^
1 warning generated.
ninja: build stopped: subcommand failed.

Unfortunately, my fix doesn't work here. It looks like the dependencies are in the wrong order in F:\svn\buildninja\build.ninja:

#############################################
# Utility command for CONFIGURE_LLVM_NATIVE

build CONFIGURE_LLVM_NATIVE: phony CMakeFiles\CONFIGURE_LLVM_NATIVE NATIVE\CMakeCache.txt CREATE_LLVM_NATIVE

#############################################
# Custom command for NATIVE\CMakeCache.txt

build NATIVE\CMakeCache.txt: CUSTOM_COMMAND || CREATE_LLVM_NATIVE
  COMMAND = cmd.exe /C "cd /D F:\svn\buildninja\NATIVE && "C:\Program Files\CMake\bin\cmake.exe" -G Ninja -DCMAKE_MAKE_PROGRAM="C:/PROGRA~2/MIB055~1/2017/PROFES~1/Common7/IDE/COMMON~1/MICROS~1/CMake/Ninja/ninja.exe" "-DCMAKE_C_COMPILER=c:/Program Files/LLVM/bin/clang-cl.exe" "-DCMAKE_CXX_COMPILER=c:/Program Files/LLVM/bin/clang-cl.exe" F:/svn/llvm -DLLVM_TARGET_IS_CROSSCOMPILE_HOST=TRUE -DLLVM_TARGETS_TO_BUILD="AArch64;AMDGPU;ARM;BPF;Hexagon;Lanai;Mips;MSP430;NVPTX;PowerPC;Sparc;SystemZ;WebAssembly;X86;XCore" -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD="" -DLLVM_DEFAULT_TARGET_TRIPLE="x86_64-pc-windows-msvc" -DLLVM_TARGET_ARCH="host" -DCMAKE_BUILD_TYPE=Release -DLLVM_USE_LINKER=lld -DLLVM_EXTERNAL_CLANG_SOURCE_DIR=f:/svn/clang"
  DESC = Configuring NATIVE LLVM...
  restat = 1

#############################################
# Utility command for LLVM-tablegen-host

build utils\TableGen\LLVM-tablegen-host: phony utils\TableGen\CMakeFiles\LLVM-tablegen-host NATIVE\bin\llvm-tblgen CONFIGURE_LLVM_NATIVE bin\llvm-tblgen.exe

#############################################
# Utility command for CLANG-tablegen-host

build tools\clang\utils\TableGen\CLANG-tablegen-host: phony tools\clang\utils\TableGen\CMakeFiles\CLANG-tablegen-host NATIVE\bin\clang-tblgen CONFIGURE_LLVM_NATIVE bin\clang-tblgen.exe utils\TableGen\LLVM-tablegen-host

The LLVM-tablegen-host dependency for CLANG-tablegen-host comes at the end, and it really looks like CONFIGURE_LLVM_NATIVE is called for both tablegen-host configs, before LLVM-tablegen-host dependency can kick in.
I've tried moving around the call to add_dependencies(), but the dependency list in the Ninja build script remains in the same order. Any advice?

[aganea]

On a different run, the Cmake callstack is a bit different:

[163/3829] Configuring NATIVE LLVM...
FAILED: NATIVE/CMakeCache.txt
cmd.exe /C "cd /D F:\svn\buildninja\NATIVE && "C:\Program Files\CMake\bin\cmake.exe" -G Ninja -DCMAKE_MAKE_PROGRAM="C:/PROGRA~2/MIB055~1/2017/PROFES~1/Common7/IDE/COMMON~1/MICROS~1/CMake/Ninja/ninja.exe" "-DCMAKE_C_COMPILER=c:/Program Files/LLVM/bin/clang-cl.exe" "-DCMAKE_CXX_COMPILER=c:/Program Files/LLVM/bin/clang-cl.exe" F:/svn/llvm -DLLVM_TARGET_IS_CROSSCOMPILE_HOST=TRUE -DLLVM_TARGETS_TO_BUILD="AArch64;AMDGPU;ARM;BPF;Hexagon;Lanai;Mips;MSP430;NVPTX;PowerPC;Sparc;SystemZ;WebAssembly;X86;XCore" -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD="" -DLLVM_DEFAULT_TARGET_TRIPLE="x86_64-pc-windows-msvc" -DLLVM_TARGET_ARCH="host" -DCMAKE_BUILD_TYPE=Release -DLLVM_USE_LINKER=lld -DLLVM_EXTERNAL_CLANG_SOURCE_DIR=f:/svn/clang"
-- The C compiler identification is Clang 7.0.0
-- The CXX compiler identification is Clang 7.0.0
-- The ASM compiler identification is Clang
-- Found assembler: c:/Program Files/LLVM/bin/clang-cl.exe
-- Check for working C compiler: c:/Program Files/LLVM/bin/clang-cl.exe
-- Check for working C compiler: c:/Program Files/LLVM/bin/clang-cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: c:/Program Files/LLVM/bin/clang-cl.exe
-- Check for working CXX compiler: c:/Program Files/LLVM/bin/clang-cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
CMake Error: Unable to open check cache file for write. F:/svn/buildninja/NATIVE/CMakeFiles/CMakeTmp/CMakeFiles/cmake.check_cache
CMake Error at C:/Program Files/CMake/share/cmake-3.12/Modules/Internal/FeatureTesting.cmake:33 (try_compile):
  Failed to configure test project build system.
Call Stack (most recent call first):
  C:/Program Files/CMake/share/cmake-3.12/Modules/Internal/FeatureTesting.cmake:79 (_record_compiler_features)
  C:/Program Files/CMake/share/cmake-3.12/Modules/Compiler/CMakeCommonCompilerMacros.cmake:94 (_record_compiler_features_cxx)
  C:/Program Files/CMake/share/cmake-3.12/Modules/CMakeDetermineCompileFeatures.cmake:56 (cmake_record_cxx_compile_features)
  C:/Program Files/CMake/share/cmake-3.12/Modules/CMakeTestCXXCompiler.cmake:62 (CMAKE_DETERMINE_COMPILE_FEATURES)
  CMakeLists.txt:35 (project)


-- Configuring incomplete, errors occurred!
See also "F:/svn/buildninja/NATIVE/CMakeFiles/CMakeOutput.log".
[176/3829] Building CXX object utils\TableGen\CMakeFiles\llvm-tblgen.dir\GlobalISelEmitter.cpp.obj
ninja: build stopped: subcommand failed.

[rnk]

In D54153#1291543, @aganea wrote:

I managed to reproduce the issue with Ninja as well. It happens rarely, 1 out 5 runs.

With that evidence, I definitely thing this extra, order-only dependency makes sense for all generators. Maybe add @beanz as a reviewer, he's the one that added this configuration, right?

[aganea]

Revert to target all generators.

In D54153#1291725, @rnk wrote:

In D54153#1291543, @aganea wrote:

I managed to reproduce the issue with Ninja as well. It happens rarely, 1 out 5 runs.

With that evidence, I definitely thing this extra, order-only dependency makes sense for all generators. Maybe add @beanz as a reviewer, he's the one that added this configuration, right?

My patch doesn't solve the Ninja issue I've mentioned above, could anybody help?

[beanz]

I’m very confused how this could happen with Ninja. All the CMake invocations are done in targets with ‘USES_TERMINAL’ set on them which puts them in the ‘console’ pool which only allows one task at a time. So there shouldn’t be a way to have more than one Ninja invocation running at a time.

[aganea]

In D54153#1291830, @beanz wrote:

I’m very confused how this could happen with Ninja. All the CMake invocations are done in targets with ‘USES_TERMINAL’ set on them which puts them in the ‘console’ pool which only allows one task at a time. So there shouldn’t be a way to have more than one Ninja invocation running at a time.

I wasn't able to reproduce the issue with Ninja. This might be linked to the AV software.

To all: can I go ahead with the patch? This fixes the Visual Studio builds at least.

[rnk]

Go for it.

In D54153#1291830, @beanz wrote:

I’m very confused how this could happen with Ninja. All the CMake invocations are done in targets with ‘USES_TERMINAL’ set on them which puts them in the ‘console’ pool which only allows one task at a time. So there shouldn’t be a way to have more than one Ninja invocation running at a time.

Then, I guess this is still an issue for makefile, xcode, and every other generator without a console pool mechanism.

cmake/modules/TableGen.cmake

174

Please add a comment here about why this dependency exists. There's no real dependency, it just exists to serialize the two build steps that share the same resource (the build directory).

Actually, I suppose the proper fix for arbitrary projects using tablegen is to chain them all together, otherwise you can imagine lld tablegen and clang tablegen racing to use the same host build dir. Ew. Perhaps... make that a FIXME for now.

[aganea]

I'm reopening this because there was an issue after committing, in the case when clang is inside llvm/tools/.
I've added AND TARGET ${project}-tablegen-host below, however this seems to hide a bigger issue, and I wanted you to be aware of it.
It seems that Clang's cmake files are executed in that case (when clang is checkedout in llvm/tools/clang), even though I didn't tell cmake that I wanted to build clang. I'm not sure that is the expected behavior, I'll let you judge.

[beanz]

It is expected that CMake will process all projects put under llvm/tools unless explicitly told not to. So, it is expected that it would process clang there. If you don't want it to process clang you need to set LLVM_TOOL_CLANG_BUILD=Off when configuring.

In terms of the error you're seeing. I'm not sure what is going on there, but the logged error doesn't make sense with the state of the code in tree today (line 165 of TableGen.cmake doesn't have a call to add_dependencies). Are you maybe building out of date sources?

[aganea]

In D54153#1335403, @beanz wrote:

It is expected that CMake will process all projects put under llvm/tools unless explicitly told not to. So, it is expected that it would process clang there. If you don't want it to process clang you need to set LLVM_TOOL_CLANG_BUILD=Off when configuring.

Ah, thank you for the explanation Chris.

In terms of the error you're seeing. I'm not sure what is going on there, but the logged error doesn't make sense with the state of the code in tree today (line 165 of TableGen.cmake doesn't have a call to add_dependencies). Are you maybe building out of date sources?

No I reverted the change so I can investigate.

cmake/modules/TableGen.cmake

if( ${${project}_TABLEGEN} STREQUAL "${target}" )
       else()
         set(${project}_TABLEGEN_EXE "${LLVM_NATIVE_BUILD}/Release/bin/${target}")
       endif()
       set(${project}_TABLEGEN_EXE ${${project}_TABLEGEN_EXE} PARENT_SCOPE)
 
       llvm_ExternalProject_BuildCmd(tblgen_build_cmd ${target}
                                     ${LLVM_NATIVE_BUILD}
                                     CONFIGURATION Release)
+      # Create an artificial dependency between tablegen projects, because they
+      # compile the same dependencies, thus using the same build folders.
+      # FIXME: A proper fix requires sequentially chaining tablegens.
+      if (NOT ${project} STREQUAL LLVM AND TARGET ${project}-tablegen-host)
+        add_dependencies(${project}-tablegen-host LLVM-tablegen-host)
+      endif()
       add_custom_command(OUTPUT ${${project}_TABLEGEN_EXE}
         COMMAND ${tblgen_build_cmd}
         DEPENDS CONFIGURE_LLVM_NATIVE ${target}
         WORKING_DIRECTORY ${LLVM_NATIVE_BUILD}
         COMMENT "Building native TableGen..."
         USES_TERMINAL)
       add_custom_target(${project}-tablegen-host DEPENDS ${${project}_TABLEGEN_EXE})
       set(${project}_TABLEGEN_TARGET ${project}-tablegen-host PARENT_SCOPE)
     endif()
   endif()
 
   if (${project} STREQUAL LLVM AND NOT LLVM_INSTALL_TOOLCHAIN_ONLY)
     if(${target} IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
         NOT LLVM_DISTRIBUTION_COMPONENTS)
       set(export_to_llvmexports EXPORT LLVMExports)
     endif()
 
     install(TARGETS ${target}
             ${export_to_llvmexports}
             RUNTIME DESTINATION ${LLVM_TOOLS_INSTALL_DIR})
   endif()
   set_property(GLOBAL APPEND PROPERTY LLVM_EXPORTS ${target})
 endmacro()