Greetings, My company has a large, predominately C++ codebase, with hundreds of targets, both for product and unit tests. In an effort to improve the compile and test time for developers, which utilizes a continuous integration infrastructure, it is desirable to compile only the targets that are affected by developer's change sets. Our approach leverages the cmake target source file information, along with the dependency graph, to identify which targets are directly affected by the changeset, and then trace the dependency graph to find all targets which depend on these files. We use 'make', so cmake does not analyze header information, so we must have a preprocessing step (makedepend or gcc -M) to identify which source files may be affected by the header files in the change set. These indirectly changed sources are fed back into the file changeset. 'make' has a limitation where if 'make target1 target2 target3' is invoked, target1, target2, and target3 are built serially, not in parallel. To get around this, we decided that the best option was to dynamically create a new [cmake] target which depends on the affected targets. This is where we could use some guidance as we have two possible approaches: 1. This could either be implemented in cmake code; by supplying a command line argument, specifying the "dynamic" target which in turn would create a target during the generation process. 2. Explicitly specify the "dynamic" target in our project's CMakeLists.txt file, and allow cmake to simply add the affected targets as a dependency to the dynamic target. Our current (attached) patch adds an option (--change-set=<filename>) for to cmake to read a (newline separated with absolute paths) file which contains the list of files in the changeset. cmake parses the file and outputs the set of affected targets and then exits before makefile generation. We would like your opinions on how to best implement this. Would it be better to handle the creation of the dummy target in CMakeLists.txt, or to handle it in cmake code? Additionally, would you be interested in adopting these changes upstream? option 1: cmake --change-set=mychanges.txt >> targets.txt create dummy target in CMakeLists.txt cmake (parses targets.txt and adds dependencies to dummy-target) make dummy-target pros: simple, small addition to cmake cons: less general, complexity moved to build scripts option 2: cmake --change-set=mychanges.txt >> targets.txt cmake --dependencies=targets.txt --dynamic-target=dummy-target make dummy-target option 3: cmake --change-set=mychanges.txt --dynamic-target=dummy-target make dummy-target pros: more general cons: more complexity introduced to cmake code I appreciate your time and look forward to your feedback. --Robert Patterson |
compile-changeset.patch
Description: Binary data
-- Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
