<div dir="ltr"><div>This patch breaks the following use case:</div><div>* Module_A depends upon Module_B</div><div>* user disables BUILD_DEFAULT_MODULES, enables Module_A</div><div>* note that after a re-configure, the CMake option for Module_B has disappeared, since it's already implicitly enabled via dependencies</div>
<div>* user wants to run a full test of Module_A and all of the code that it depends upon (including Module_B)</div><div>* Module_B won't be tested and can't be explicitly enabled since it's hidden</div><div><br>
</div><div>Sure, there's a workaround where the user:</div><div>* disables Module_A</div><div>*re-configures</div><div>*enables Module_B</div><div>*re-configures</div><div>*enables Modules_A</div><div>*re-configures</div>
<div>but I don't think it's reasonable.</div><div><br></div><div>----</div><div><br></div><div>I sympathize with the original complaint, but I think that the CMake configuration process is the wrong place to fix it. As I understand (correct me if I'm missing something), the two big functions of testing in ITK are:</div>
<div>* to be run manually by users, to provide confidence that a build is functional<br></div><div>* to be automatically run on dashboards, reporting regressions</div><div><br></div><div>When a user runs tests manually, they probably want to test all of the modules that are enabled (implicitly or explicitly). Testing only the top-level explicitly-enabled modules does not inspire full confidence in the software, as the underlying code (maybe something in Module_ITKCommon) could be broken. If a user just wants to speed up their build times, they should be disabling BUILD_TESTING all together. If an impatient developer wants a fast build, as they're only testing a specific module(s), then "make <modulename1>-all [<modulename2>-all]..." works just fine...as they still have to type the "make" command either way.  In MSVC it's also easy to select a specific target to build, instead of the solution or "Build-all" target (or whatever it's called).</div>
<div><br></div><div>When tests are run on dashboards, I agree that it makes no sense to build tests that will never be run, which easily happens if the configuration is using the <span style="color:rgb(0,0,0);font-size:14px">INCLUDE_LABEL option to only run tests with a certain label(s). The solution is to fix the dashboard script. I think a simple solution is:</span></div>
<div><span style="color:rgb(0,0,0);font-size:14px">* add a new optional variable to itk_common.cmake: "</span><font color="#000000"><span style="font-size:14px">CTEST_BUILD_ARGS"</span></font></div><div><font color="#000000"><span style="font-size:14px">* on </span></font><span style="color:rgb(0,0,0);font-size:14px">itk_common.cmake:405, change "</span><font color="#000000"><span style="font-size:14px">ctest_build()" to pass </span></font><span style="color:rgb(0,0,0);font-size:14px">"${</span><font color="#000000"><span style="font-size:14px">CTEST_BUILD_ARGS}" as an argument</span></font></div>
<div><font color="#000000"><span style="font-size:14px">* a dashboard client script does: "set( </span></font><span style="color:rgb(0,0,0);font-size:14px">CTEST_BUILD_ARGS </span><span style="font-family:arial,sans-serif;font-size:13px">TARGET ${</span><span style="font-family:arial,sans-serif;font-size:13px">modulename}-all</span><span style="font-family:arial,sans-serif;font-size:13px"> )"</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><font face="arial, sans-serif">The only issue is that "</font><span style="color:rgb(0,0,0);font-size:14px">ctest_build()"</span><font face="arial, sans-serif"> can only take a single alternate target as an argument, not a list of targets (improving this would require some non-trivial changes to CMake). For the case of testing Remote modules, however, only the one "</font><span style="font-size:13px;font-family:arial,sans-serif">${</span><span style="font-size:13px;font-family:arial,sans-serif">modulename}</span><span style="font-family:arial,sans-serif">-all" target for the remote module being tested needs to be built.</span></div>
<div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 16, 2014 at 5:31 PM, Matt McCormick <span dir="ltr"><<a href="mailto:matt.mccormick@kitware.com" target="_blank">matt.mccormick@kitware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Here is a patch that only build the tests for Modules specified<br>
explicitly when BUILD_DEFAULT_MODULES is OFF.<br>
<br>
  <a href="http://review.source.kitware.com/#/c/14063/" target="_blank">http://review.source.kitware.com/#/c/14063/</a><br>
<br>
Thanks,<br>
Matt<br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, Jan 16, 2014 at 3:50 PM, Brian Helba <<a href="mailto:brian.helba@kitware.com">brian.helba@kitware.com</a>> wrote:<br>
> For Makefile-based code generation, building with "make <modulename>-all"<br>
> should only build the module, tests, and its recursive code dependencies. It<br>
> should be possible to call<br>
> ctest_build(.. TARGET <modulename>-all ..) in the CTest driver script.<br>
><br>
> I'm not sure about this, but I would hope that ctest_build can do the same<br>
> thing to directly build MSVC projects, as opposed to the entire solution.<br>
><br>
><br>
> On Thu, Jan 16, 2014 at 11:46 AM, Bradley Lowekamp <<a href="mailto:blowekamp@mail.nih.gov">blowekamp@mail.nih.gov</a>><br>
> wrote:<br>
>><br>
>><br>
>> On Jan 16, 2014, at 11:28 AM, Bill Lorensen <<a href="mailto:bill.lorensen@gmail.com">bill.lorensen@gmail.com</a>><br>
>> wrote:<br>
>><br>
>><br>
>> It would be great if there were some way to turn off the building of<br>
>> the dependent module tests.<br>
>><br>
>><br>
>> +1<br>
>><br>
>><br>
>> This should be added to the infrastructure improvement list.<br>
>><br>
>> I just tried to build the Core/Common module, and most of the toolkit was<br>
>> still turned on and the testing built.<br>
>><br>
>> Brad<br>
>><br>
>> _______________________________________________<br>
>> Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
>><br>
>> Visit other Kitware open-source projects at<br>
>> <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
>><br>
>> Kitware offers ITK Training Courses, for more information visit:<br>
>> <a href="http://kitware.com/products/protraining.php" target="_blank">http://kitware.com/products/protraining.php</a><br>
>><br>
>> Please keep messages on-topic and check the ITK FAQ at:<br>
>> <a href="http://www.itk.org/Wiki/ITK_FAQ" target="_blank">http://www.itk.org/Wiki/ITK_FAQ</a><br>
>><br>
>> Follow this link to subscribe/unsubscribe:<br>
>> <a href="http://www.itk.org/mailman/listinfo/insight-developers" target="_blank">http://www.itk.org/mailman/listinfo/insight-developers</a><br>
>><br>
>> _______________________________________________<br>
>> Community mailing list<br>
>> <a href="mailto:Community@itk.org">Community@itk.org</a><br>
>> <a href="http://public.kitware.com/cgi-bin/mailman/listinfo/community" target="_blank">http://public.kitware.com/cgi-bin/mailman/listinfo/community</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> Brian Helba<br>
> Medical Imaging<br>
> Kitware, Inc.<br>
><br>
> _______________________________________________<br>
> Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
><br>
> Visit other Kitware open-source projects at<br>
> <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
><br>
> Kitware offers ITK Training Courses, for more information visit:<br>
> <a href="http://kitware.com/products/protraining.php" target="_blank">http://kitware.com/products/protraining.php</a><br>
><br>
> Please keep messages on-topic and check the ITK FAQ at:<br>
> <a href="http://www.itk.org/Wiki/ITK_FAQ" target="_blank">http://www.itk.org/Wiki/ITK_FAQ</a><br>
><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="http://www.itk.org/mailman/listinfo/insight-developers" target="_blank">http://www.itk.org/mailman/listinfo/insight-developers</a><br>
><br>
> _______________________________________________<br>
> Community mailing list<br>
> <a href="mailto:Community@itk.org">Community@itk.org</a><br>
> <a href="http://public.kitware.com/cgi-bin/mailman/listinfo/community" target="_blank">http://public.kitware.com/cgi-bin/mailman/listinfo/community</a><br>
><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Brian Helba<br>Medical Imaging<br>Kitware, Inc.<br>
</div>