[Insight-developers] CMakeLists changes

Thu, 28 Feb 2002 14:30:50 -0500

Let's defer to the tcon for this discussion.

-----Original Message-----
From: Bill Hoffman [mailto:bill.hoffman@kitware.com]
Sent: Thursday, February 28, 2002 2:30 PM
To: Miller, James V (CRD); Lorensen, William E (CRD); insight-Developers
Subject: RE: [Insight-developers] CMakeLists changes

I think it is both, people have often complained about how long
it takes to load the targets into the workspace.   With the Microsoft
compile I am not sure dlls would solve 2 anyway, I think it would 
still instantiate all the classes in the exe anyway, unless we compiled
with ITK_MANUAL_INSTANTATE, which I think would be a much harder task since
you want it both ways.  (you want to compile some of the library with
ITK_MANUAL and some of it let the compiler see all the code.

-Bill

At 02:20 PM 2/28/2002 -0500, Miller, James V (CRD) wrote:
>What's the motivating factor here?
>
>1) Too many targets in the workspace?
>2) Too large a footprint on disk for all the exe's?
>
>If it's the former, then having the default build only construct a few tests
>will be satisfactory.
>
>If it's the latter, why don't we address the problem by building shared 
>libraries. Can't we construct a methodology where a given set of instantiations
>are placed in a series of shared libraries that are linked into the various tests?
>These would include the "normal" instantiations of 2D and 3D vectors, points, 
>2D and 3D images of the standard types, maybe the default readers, standard
>calculators, standard iterators, etc. The individual filter instantiations would
>still have to be generated on a test by test basis but the code shared across 
>tests could be placed in libraries.
>
>
>
>
>
>-----Original Message-----
>From: Bill Hoffman [mailto:bill.hoffman@kitware.com]
>Sent: Thursday, February 28, 2002 2:14 PM
>To: Miller, James V (CRD); Lorensen, William E (CRD); insight-Developers
>Subject: RE: [Insight-developers] CMakeLists changes
>
>
>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 