[Insight-developers] CMakeLists changes

[Bill Hoffman]

That is true, but it might force a level of maturity, as bad tests would be 
commented out or fixed.

Tcl wrapping would have the same problem, if one class could not be wrapped,
all the tcl tests would be lost.   At least this would be only a directory
of tests.    I really do think it is time that ITK at least compiles.
Perhaps if people could not run there test, the would be less likely to
check in code that does not compile.


-Bill


At 02:08 PM 2/28/2002 -0500, Miller, James V (CRD) wrote:
>But if one test does not or will not compile, testing for the entire
>directory will be lost.  I don't think our code is to the level of maturity
>to tolerate an entire directory of tests not being executed.
>
>
>-----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 
>
>_______________________________________________
>Insight-developers mailing list
>Insight-developers@public.kitware.com
>http://public.kitware.com/mailman/listinfo/insight-developers