I consulted the developers and in the end we decided, that a separate CMAKE_BUILD_TYPE just for testing will allow us to avoid all these problems in a pretty clean way. I'll just EXCLUDE_FROM_ALL the test targets in Debug and Release, and exclude the regular targets in Testing. This way, they'll be able to build any subtree of tests by simply typing 'make -j'.
Is this a common approach ? How do you guys manage these issues ? WK ----- Reply message ----- From: "wmkna...@gmail.com" <wmkna...@gmail.com> To: <cmake@cmake.org> Subject: Re: [CMake] Building all tests in parallel (whole subtrees) Date: Thu, Jan 24, 2013 12:42 Actually, scratch that. Option 2) is not so great, because it only allows me to build the tests from the top level (all of them), or from the "bottom" (just one test). And parallel builds still break. So I guess I need a brand new idea, or another fix for that one...----- Reply message ----- From: "wmkna...@gmail.com" <wmkna...@gmail.com> To: <cmake@cmake.org> Subject: Re: [CMake] Building all tests in parallel (whole subtrees) Date: Thu, Jan 24, 2013 12:26 Could you describe your approach in more detail ? If I understand it correctly, it requires quite a bit of manual maintenance... I've tried the following so far: 1) Created a "ut" target on top and for every unit test did add_dependency(ut that_ut). That works fine in parallel, but builds *all* the tests - not enough granularity. 2) Created a "ut" target at the top (with no dependencies) and set the global property ALLOW_DUPLICATE_CUSTOM_TARGETS and USE_SUBDIRS to true. In every directory with tests in it, I created a "ut" target that depends on building the test. That works exactly how I want it to, but breaks when building in parallel (race conditions in writing to files that are common dependencies). This approach would require zero maintenance, so it would be my preferred one, but I don't know if the parallelism issue can be fixed. Ideas ? 3) I managed to force ctest to build the tests in parallel, but when calling ctest with -j (multiple tests building in parallel), the same issues cropped up as in 2) and I prefer 2) anyway. Hints on fixing 2) would be very much appreciated. Time is running out... ;) Thanks, WK----- Reply message ----- From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca> To: "Matthew Woehlke" <matthew.woeh...@kitware.com> Cc: <cmake@cmake.org> Subject: [CMake] Building all tests in parallel (whole subtrees) Date: Thu, Jan 24, 2013 05:52 On 2013-01-23 19:07-0500 Matthew Woehlke wrote: > On 2013-01-23 18:08, Wojciech Knapik wrote: >> I set up targets that build the unit test executables and >> marked them with EXCLUDE_FROM_ALL, because I don't want to tie building >> them to building the application code. Now I need a way to build and run >> these tests en masse, since there are too many to do it one at a time. >> >> Ideally I'd like to have a make target, that I could call to build all >> unit tests in the current directory and below *in*parallel*. @Wojciech: I do exactly what you describe for a number of build systems I am maintaining, I create a whole system of custom test targets with all the required file and target dependencies between them (and other standard targets such as libraries and executables) with the combination of add_custom_command/add_custom_target/add_dependencies commands. I also maintain a hierarchy of target dependencies using the combination of add_custom_target/add_dependencies so that there is one overall target (which I happen to call test_everything) which depends on every other test target. > I'm not sure if this is possible (or at least feasible)... @Matthew and Wojciech: Whether ordinary or custom targets can be built in parallel depends on the back-end being used. For the "Unix Makefiles" generator it is simple; make -j8 test_everything gets the job done. Other generators I have used with parallel-build capability are "MSYS Makefiles" and "MinGW Makefiles" on Windows (actually Wine in my case which I use as a convenient and free in both senses test Windows platform under Linux). I haven't tried the ""NMake Makefiles JOM" generator yet, but I plan to do so. The jom backend (unlike nmake) does have parallel build capability (see http://qt-project.org/wiki/jom project). The jom application is part of the ordinary Qt install for Windows (or Wine) so I plan to give the parallel build capabilities of jom a try in the future. > different generators may or may not have the concept of targets in > directories. I think you would need to create a uniquely named target per directory. @Matthew: That should not be a concern. Targets are a global concept in CMake so are independent of which subdirectory they are created in. So the test_everything target mentioned above runs test targets that have been created in different subdirectories without issues. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
-- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
