Alan W. Irwin wrote: > So the rule seems to be that parallel builds do not work if there are two > or more separate custom targets that file depend directly or indirectly > (via > some custom command file dependency chain) on the same output files. > > Another way of summarizing these results is that file depends must be > minimized and/or custom target depends maximized in order for parallel > builds to work properly.
This is correct. > My guess is I should be able to work around this CMake issue by appropriate > changes to the PLplot build system although I have a number of these > parallel build issues and the copy problem was only the most obvious. > > I do regard this as a CMake issue. Normally, the shoe is on the other > foot, > and the build system developer is desperately trying to make sure that all > the CMake file depends are obviously in place locally rather than depending > on a long easily-broken chain of dependencies to do it for them in a > minimalist way. So the big question is whether CMake can be modified so > that minimalist file depends and/or maximal (and unintuitive) target > depends > are not required in order for parallel builds to work properly. I don't see how CMake can automatically fix this. If two targets think they know how to build the same file how is CMake supposed to know which one is the correct target to build first? Consider this: 1.) Split your example into two separate directories 2.) Put the first-level custom commands in a target in one dir 3.) Put the second-level custom commands in a target in the other dir 4.) Try to build Without explicit dependence between the two targets there is no way the target in the second directory can know it must wait for the target in the first directory to build. It doesn't even know about the first-level custom command rules or that the input to one if its second-level custom commands is a generated file. The second directory's target will try to build and complain that input files are missing. This problem arises because CMake does not track file-level dependencies globally. It actually can't because some target build environments like the VS and Xcode IDEs do not provide this capability. File-level dependencies must be divided into targets. In your case the target-level dependency that must be added is a logical high-level statement of dependence: "I need all the 'tcl_examples' to be ready before I use them for anything" -Brad _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
