# Building VTK modules with dependencies results in race condition in make
**URL:** https://discourse.vtk.org/t/building-vtk-modules-with-dependencies-results-in-race-condition-in-make/1711
**Category:** Development
**Created:** [September 6, 2019, 10:22am UTC](https://discourse.vtk.org/t/building-vtk-modules-with-dependencies-results-in-race-condition-in-make/1711 "2019-09-06T10:22:35Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@lhofmann](https://discourse.vtk.org/u/lhofmann)
#### Post date: [September 6, 2019, 10:22am UTC](https://discourse.vtk.org/t/building-vtk-modules-with-dependencies-results-in-race-condition-in-make/1711/1 "2019-09-06T10:22:35Z")
I have a project that builds multiple VTK modules, and some depend on other modules built in the same project. There seems to be some kind of race condition in the resulting Makefiles, that causes an error if a module `ModuleB` depends on a `ModuleA`.
```auto
vtkWrapHierarchy: couldn't open file .../build/lib/vtk/hierarchy/MyProject/ModuleA-hierarchy.txt
make[2]: *** [ModuleB/CMakeFiles/ModuleB-hierarchy.dir/build.make:66: lib/vtk/hierarchy/MyProject/ModuleB-hierarchy.txt] Error 1
make[1]: *** [CMakeFiles/Makefile2:234: ModuleB/CMakeFiles/ModuleB-hierarchy.dir/all] Error 2
make: *** [Makefile:130: all] Error 2
```
Running make without invoking CMake again multiple times finally gets rid of this error; and when I’m lucky it works on the first try (therefore I think this is a race condition of some sorts).
I have broken down the problem to a minimal example (`vtk_module_wrap_python` is required, otherwise the hierarchies are not built). The project contains two subdirectories, where `ModuleA` and `ModuleB` are defined (they contain no code at all in the minimal example). The essential parts are listed below.
The full source is here: [vtk9\_race.tar.gz](https://discourse.vtk.org/uploads/short-url/3TNezVgZvHUsAg40qpNFsc3Vj0d.gz) (901 Bytes)
I have tested this with VTK from the master branch and with VTK contained in ParaView-v5.7.0-RC2.
- The error seems to only happen when using `make` for building (with `-j1` and without), it seems to work fine using `ninja`.
- It also works, if I first build target `ModuleA-hierarchy`, i.e., run `make ModuleA-hierarchy; make`.
- The problem only occurs in CMake \> 3.12. I successfully tested versions 3.8.0 and 3.12.2, but it breaks using versions 3.13.4 and 3.15.3.
### CMakeLists.txt
```auto
cmake_minimum_required(VERSION 3.8 FATAL_ERROR)
project(MyProject)
find_package(VTK REQUIRED)
option(BUILD_SHARED_LIBS "Build shared libraries" ON)
include(GNUInstallDirs)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/${CMAKE_INSTALL_BINDIR}")
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/${CMAKE_INSTALL_LIBDIR}")
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/${CMAKE_INSTALL_LIBDIR}")
file(RELATIVE_PATH python_module_path "${VTK_PREFIX_PATH}" "${VTK_PYTHONPATH}")
vtk_module_find_modules(vtk_module_files "${CMAKE_CURRENT_SOURCE_DIR}")
vtk_module_scan(
MODULE_FILES ${vtk_module_files}
PROVIDES_MODULES VTK_MODULES
WANT_BY_DEFAULT ON
)
vtk_module_build(
MODULES ${VTK_MODULES}
INSTALL_HEADERS OFF
)
vtk_module_wrap_python(
MODULES ${VTK_MODULES}
INSTALL_HEADERS OFF
PYTHON_PACKAGE ${CMAKE_PROJECT_NAME}
MODULE_DESTINATION ${python_module_path}
)
```
### ModuleA/vtk.module
```auto
NAME
ModuleA
```
### ModuleB/vtk.module
```auto
NAME
ModuleB
DEPENDS
ModuleA
```
---
### Author:  [@lhofmann](https://discourse.vtk.org/u/lhofmann)
#### Post date: [September 6, 2019, 12:20pm UTC](https://discourse.vtk.org/t/building-vtk-modules-with-dependencies-results-in-race-condition-in-make/1711/2 "2019-09-06T12:20:27Z")
So, I did some digging in the VTK source, and found [this comment](https://gitlab.kitware.com/vtk/vtk/blob/0a48753137e5f98d9b59b5a09f91cb4ce1b159fc/CMake/vtkModule.cmake#L2684):
```auto
# Non-alias target modules are external and should already have their file
# generated.
```
The solution apparently is to give all modules names like `MY::ModuleA` and use these (aliased) targets instead (see below).
No idea though, why the original setup still works with older CMake versions.
### ModuleA/vtk.module
```auto
NAME
MY::ModuleA
LIBRARY_NAME
myModuleA
```
### ModuleB/vtk.module
```auto
NAME
MY::ModuleB
LIBRARY_NAME
myModuleB
DEPENDS
MY::ModuleA
```
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [October 4, 2019, 7:40pm UTC](https://discourse.vtk.org/t/building-vtk-modules-with-dependencies-results-in-race-condition-in-make/1711/3 "2019-10-04T19:40:35Z")
This is probably an oversight in the logic around that comment. Looking into it.
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [October 4, 2019, 7:43pm UTC](https://discourse.vtk.org/t/building-vtk-modules-with-dependencies-results-in-race-condition-in-make/1711/4 "2019-10-04T19:43:11Z")
Please try this change: [https://gitlab.kitware.com/vtk/vtk/merge\_requests/6039](https://gitlab.kitware.com/vtk/vtk/merge_requests/6039)
---
### Author:  [@Charles\_Gueunet](https://discourse.vtk.org/u/Charles_Gueunet)
#### Post date: [October 7, 2019, 11:35am UTC](https://discourse.vtk.org/t/building-vtk-modules-with-dependencies-results-in-race-condition-in-make/1711/5 "2019-10-07T11:35:23Z")
After some tests on my side, it seems another solution could be to force the target creating the hierarchy file to be executed prior to the main target.
On my case, for each module I have a:
```auto
add_dependeencies(${NAME} ${NAME}-hierarchy)
```
Also, you can also call `cmake --taget ModuleB-hierarchy` explicitely to force the computation of the missing file.
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [October 7, 2019, 2:31pm UTC](https://discourse.vtk.org/t/building-vtk-modules-with-dependencies-results-in-race-condition-in-make/1711/6 "2019-10-07T14:31:57Z")
That’s not a valid solution; the module system should Just Work™ at this level. Does the MR above fix the problem for you?
---
### Author:  [@lhofmann](https://discourse.vtk.org/u/lhofmann)
#### Post date: [October 8, 2019, 7:57am UTC](https://discourse.vtk.org/t/building-vtk-modules-with-dependencies-results-in-race-condition-in-make/1711/7 "2019-10-08T07:57:46Z")
I think the `NOT` in line 2685 of your patch is not supposed to be there.
Using the following patch, the problem is fixed for me:
```diff
--- a/CMake/vtkModule.cmake 2019-08-13 10:21:06.614636564 +0200
+++ b/CMake/vtkModule.cmake 2019-10-08 09:51:20.888553903 +0200
@@ -2677,13 +2677,12 @@
"${_vtk_hierarchy_depend_hierarchy}")
# Find the hierarchy target of the module.
- get_property(_vtk_hierarchy_module_is_alias
+ get_property(_vtk_hierarchy_module_is_imported
TARGET "${_vtk_hierarchy_depend}"
- PROPERTY ALIASED_TARGET
- SET)
+ PROPERTY IMPORTED)
# Non-alias target modules are external and should already have their file
# generated.
- if (NOT _vtk_hierarchy_module_is_alias)
+ if (_vtk_hierarchy_module_is_imported)
continue ()
endif ()
```
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [October 8, 2019, 3:10pm UTC](https://discourse.vtk.org/t/building-vtk-modules-with-dependencies-results-in-race-condition-in-make/1711/8 "2019-10-08T15:10:28Z")
Oops. Thanks for the test. I’ve updated the branch and submitted it for testing (now that the atomic stuff has been addressed).