<br>Hi Gaetan,<br><br>I agree that it is an interesting feature to be able to run several tests simultaneously.<br><br>It is true that *the large majority* of ITK tests do not depend on the output from <br>previous tests. There are however some exceptions, for example, the hole filling
<br>filters apply their computation on the output of the binary threshold image filter test.<br><br>You may get away with the lack of dependencies if you run a non-clean build,<br>with the drawback that if test A depends on the output of test B, and yesterday
<br>test B was broken, then Today's test A will appear as broken, even if the code<br>for both A and B is fine today.<br><br>Any effort that reduces the computation time of the tests is worth of consideration,<br>because that also increases the chances that we will actually run the full testing
<br>before committing code to the repository ( I say this with the guilt of having <br>committed code on Monday without running the full testing...)<br><br>The dependencies are probably very few, the challenge is to find them :-/
<br>and then to make sure that they are never introduced again. I would guess<br>that most of the dependencies can be solved by adding the output file to the<br>Data/Input or the Data/Baseline directory, assuming that the file is not too big.
<br><br><br> Luis<br><br><br><br>----------------------------------------------------------------------------------------------------------<br><div><span class="gmail_quote">On 7/25/07, <b class="gmail_sendername">Gaëtan Lehmann
</b> <<a href="mailto:gaetan.lehmann@jouy.inra.fr">gaetan.lehmann@jouy.inra.fr</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Selon Mathieu Malaterre <<a href="mailto:mathieu.malaterre@gmail.com">mathieu.malaterre@gmail.com</a>>:<br><br>> Hi Alex "hanfei",<br>><br>> I believe there is nothing in the ADD_TEST to declare dependencies.
<br>> So chance is that you would run a test (depending on output from<br>> another) *before* the dependant test is run.<br>><br>> Is this correct ?<br><br>But that's also the case when using the -I option, or any option which allow to
<br>restrict the set of tests.<br><br>The ITK tests for example don't seem to have a dependency on other tests.<br>And the itkTestDriver program can now be used to easily run a test program and<br>test the output images in a single ADD_TEST() command, so there is no
<br>dependencies on other tests like with ImageCompare.<br><br>That's surely not possible for all the projects, but being able to run the tests<br>in parallel as an option (-j ?) would definitively be a nice feature.<br>
<br>><br>> -Mathieu<br>><br>> On 7/24/07, Dr. Alex. GOUAILLARD <<a href="mailto:hanfei@caltech.edu">hanfei@caltech.edu</a>> wrote:<br>> > hi all,<br>> ><br>> > Annoyed by the time needed by the ITK test suite to run, I made a little
<br>> > test trying to use ctest in a multithreaded fashion (thanks to the -I<br>> > option). Attached is a little test that is yet neither automatic or<br>> > complete, but that already give nice results on windows. It could be
<br>> > directly extended to deal with the memcheck command, which would be<br>> > great too (as it is even slower).<br>> ><br>> > compile it, copy it in your build directory, and it should work fine.
<br>> ><br>> > It first fake running ctest on the first test, for you to read the total<br>> > number of tests. It is then prompting you for that number, and launch 8<br>> > threads (you can change that number in the code) each running
<br>> > MaxNumberOfTest / 8 tests. It prints the logs in files named<br>> > ctest.log.<ThreadNumber><br>> ><br>> > pros:<br>> > -> On my 8 cores (2 4-cores) machine the gain is indeed a factor 8. 1012
<br>> > ITK tests in 5 mn (yum!)<br>> ><br>> > cons:<br>> > -> cmake is trying to write on some temp files, and all but the first<br>> > fail to do that.<br>> > -> I did not address merging and writing the resulting xml files for
<br>> > dashboard submission. I need to figure how to redirect each individual<br>> > ctest xml output first, then parsing and merging should not really be an<br>> > issue.<br>> ><br>> > questions:
<br>> > -> how to use ITK framework to make it plateform independent?<br>> > -> how to get the number of cores automatically?<br>> > -> how to be compliant with the existing 1: writing temp files?
<br>> > -> how to be compliant with the existant 2: how to redirect the xml output?<br>> ><br>> > alex "hanfei"<br>> ><br>> > _______________________________________________<br>> > CMake mailing list
<br>> > <a href="mailto:CMake@cmake.org">CMake@cmake.org</a><br>> > <a href="http://www.cmake.org/mailman/listinfo/cmake">http://www.cmake.org/mailman/listinfo/cmake</a><br>> ><br>> ><br>><br>>
<br>> --<br>> Mathieu<br>> _______________________________________________<br>> Insight-users mailing list<br>> <a href="mailto:Insight-users@itk.org">Insight-users@itk.org</a><br>> <a href="http://www.itk.org/mailman/listinfo/insight-users">
http://www.itk.org/mailman/listinfo/insight-users</a><br>><br><br><br>_______________________________________________<br>CMake mailing list<br><a href="mailto:CMake@cmake.org">CMake@cmake.org</a><br><a href="http://www.cmake.org/mailman/listinfo/cmake">
http://www.cmake.org/mailman/listinfo/cmake</a><br></blockquote></div><br>