[Insight-developers] CMakeLists changes

[Bill Hoffman]

I don't think it would add that much complexity to the process.

For one extra step in adding a new test, we would get the following:

1. faster loading of visual studio projects
2. smaller disk foot print for ITK with all tests built
3. fast compile times.


Right now to add a test, you:

1. create a cxx file with main that returns an int
2. edit the cmakelist file :
ADD_TEST(newtest newtest)
ADD_EXECUTABLE(newtest newtest)


With my approach, you would do this:

1. create a cxx file with function that returns an int
2. edit the cmakelist file:
ADD_TEST(TestDriver TestDriver newtest)
SOURCE_FILES(TEST_SRCS ... newtest)

3. edit the TestDriver.cxx, and add ITK_REGISTER_TEST(newtest)


So, there would be one extra step, step 3.

The downside would be:
1. if a test failed to compile, it would cause other tests not to compile.
(if a test crashed, it would be no different than now, as the other tests would
still run.)



At 01:47 PM 2/28/2002 -0500, Lorensen, William E (CRD) wrote:
>I think we just need to discipline ourselves. I don't want to make the testing any more compilcated
>that it is.
>
>If we require the "HeaderTest" programs to be tested it may catch some global erors.
>
>
>
>-----Original Message-----
>From: Bill Hoffman [mailto:bill.hoffman@kitware.com]
>Sent: Thursday, February 28, 2002 1:43 PM
>To: Lorensen, William E (CRD); insight-Developers
>Subject: RE: [Insight-developers] CMakeLists changes
>
>
>OK, but there is no way to enforce that developers turn on the testing.
>
>How about this...
>
>The current problem is that ITK builds too many .exe files.
>In VTK this is not a problem because the majority of the tests
>are written in Tcl, so there is one executable vtk.exe that is used
>to run all the tests.   
>
>What if for each library :
>Algorithms Common Local Patented BasicFilters IO Numerics
>
>We created a TestDriver exe program.  It would compile all of the
>tests for that directory into one executable, allowing shared template
>instances to be combined into the exe file.   It would take a command line
>argument that was the name of the test to run.   We could take all
>the existing tests and just change the name of main to the name of the test.
>And add a register step in the TestDriver.cxx main.
>
>For example:
>
>itkAlgorihmsTests.cxx:
>
>std::map<std::string, mainfuncpointer> TestMap;
>#define ITK_REGISTER_TEST(test) \
>extern int test(int ac, char** av); \
>TestMap[##test] = test; 
>
>void RegisterTests()
>{
>  ITK_REGISTER_TEST(itkBinaryMinMaxCurvatureFlowImageFilterTest);
>  ITK_REGISTER_TEST(itkCurvatureFlowTest);
>}
>
>
>main(ac, av)
>{
>  RegisterTests();  // create test map strings to function pointers
>  return (*TestMap[av[1]])(ac, av);  // run the test from the command line
>}
>
>
>The downside would be that if one test failed to compile, none of the
>tests would run.  However, that is the same situation that you have in
>VTK, if Common does not build, non of the tcl tests are run.
>
>This might be a better way to manage C++ tests.
>
>-Bill
>
>
>At 11:49 AM 2/28/2002 -0500, Lorensen, William E (CRD) wrote:
>>These are great suggestions.
>>
>>However, as developers we should always have ITK_BUILD_ALL_TESTS ON.
>>
>>Bill
>>
>>-----Original Message-----
>>From: Bill Hoffman [mailto:bill.hoffman@kitware.com]
>>Sent: Thursday, February 28, 2002 11:45 AM
>>To: insight-Developers
>>Subject: [Insight-developers] CMakeLists changes
>>
>>
>>I would like to suggest the following changes:
>>
>>1. Add a CMAKE variable ITK_VTK_INTEGRATION which defaults to OFF.
>>ITK will not look for VTK unless this is turned on.  This will
>>allow you to build ITK without VTK, even if you have VTK installed
>>on your machine, currently you can not do that.
>>
>>
>>2. Add a CMAKE variable ITK_BUILD_ALL_TESTS which defaults to OFF.
>>If this is ON, all the current executables would be built for ITK.
>>If this is OFF, then only a subset of the test executables will be built.
>>Perhaps one from each directory: 
>>Algorithms Common Local Patented BasicFilters IO Numerics
>>
>>Seven executables, would be more manageable than the current 140 or so,
>>but would also allow people to know if it was building or not.
>>We talked about this at the meeting, but I don't see a bug tracker entry
>>for it.
>>
>>-Bill
>>
>>_______________________________________________
>>Insight-developers mailing list
>>Insight-developers@public.kitware.com
>>http://public.kitware.com/mailman/listinfo/insight-developers