[CMake] Re: [Dart] CMake & Dart2 general design question

[Andy Cedilnik]

Hi Anton,

Great. Thanks for testing it.

       Andy

Anton Deguet wrote:

>Hi Andy
>
>I tested it and it works.  The default DartTestfile.txt now has a
>INCLUDE() for the file I generated.  The only difference with your
>example is that I use a post-build command to generate the list of
>tests.  We use CppUnit to write our test programs and the list of known
>tests is embedded in the code.  The only simple way to know which tests
>have been implemented is to run the test program itself with a "--list"
>option.  We added "--dart [-d]" to generate a Dart compatible output.
>
>Since we do that for a many libraries, I created a CMake macro:
>MACRO(CISST_ADD_TESTS testProgram)
>  ADD_CUSTOM_COMMAND(TARGET ${testProgram}
>                     POST_BUILD
>                     COMMAND ${EXECUTABLE_OUTPUT_PATH}/${testProgram}
>                     ARGS -d >
>${CMAKE_CURRENT_BINARY_DIR}/DartTestfile-${testProgram}.txt
>                     COMMENT "Generating
>DartTestfile-${testProgram}.txt")
>
>  SET_DIRECTORY_PROPERTIES(PROPERTIES TEST_INCLUDE_FILE
>                   
>"${CMAKE_CURRENT_BINARY_DIR}/DartTestfile-${testProgram}.txt")
>
>ENDMACRO(CISST_ADD_TESTS)
>
>
>I can now do:
>make clean
>make
>make test
>ctest -V -D Experimental
>
>And everything works as expected.  Thanks a lot.
>
>Anton
>
>
>
>On Tue, 2005-06-07 at 10:01, Andy Cedilnik wrote:
>  
>
>>Hi Anton,
>>
>>The feature is in.
>>
>>There is example in kwsys (CTestTest).
>>
>>The idea is:
>>
>>Create a cmake file, let say ExtraTest.cmake.in and put in whatever code
>>you want.
>>Then use configure command to process any options that you need in that
>>file.
>>
>>      CONFIGURE_FILE("${CMAKE_CURRENT_SOURCE_DIR}/ExtraTest.cmake.in"
>>         "${CMAKE_CURRENT_BINARY_DIR}/ExtraTest.cmake")
>>
>>Now, add the following command:
>>
>>      SET_DIRECTORY_PROPERTIES(PROPERTIES TEST_INCLUDE_FILE
>>        "${CMAKE_CURRENT_BINARY_DIR}/ExtraTest.cmake")
>>
>>Please test if it works for your case.
>>
>>Thank you.
>>
>>       Andy
>>
>>Andy Cedilnik wrote:
>>
>>    
>>
>>>Hi Anton,
>>>
>>>I will add similar feature to CMake. The feature will be to include a
>>>file in CTest input file. This way you will be able to generate this
>>>file at any point in time.
>>>
>>>      Andy
>>>
>>>Anton Deguet wrote:
>>>
>>> 
>>>
>>>      
>>>
>>>>Hi Andy,
>>>>
>>>>I am pretty happy to report that my idea works ... somewhat.  I believe
>>>>this is because our tree is pretty simple and I only overwrite the
>>>>DartTestfile.txt in the leaves:
>>>>
>>>>main
>>>>+- lib1
>>>>+- lib2
>>>>
>>>>In the main directory, CMakeLists.txt contains:
>>>>
>>>>ENABLE_TESTING()
>>>>INCLUDE(Dart)
>>>>
>>>>SET (DROP_METHOD "xmlrpc")
>>>>SET (DROP_SITE "http://myserver.net:8081")
>>>>SET (DROP_LOCATION "cisst")
>>>>SET (COMPRESS_SUBMISSION ON)
>>>>
>>>>MACRO(CISST_ADD_TESTS testProgram)
>>>>ADD_CUSTOM_COMMAND(TARGET ${testProgram}
>>>>                   POST_BUILD
>>>>                   COMMAND ${EXECUTABLE_OUTPUT_PATH}/${testProgram}
>>>>                   ARGS -d
>>>>${CMAKE_CURRENT_BINARY_DIR}/DartTestfile.txt
>>>>                   COMMENT "Generating DartTestfile.txt")
>>>>ENDMACRO(CISST_ADD_TESTS)
>>>>
>>>>Then, in each lib, I compile a single test program and use the macro
>>>>defined above:
>>>>
>>>>ADD_EXECUTABLE(cisstCommonTests ${SOURCE_FILES} ${HEADER_FILES})
>>>>
>>>>CISST_ADD_TESTS(cisstCommonTests)
>>>>
>>>>This works very well with:
>>>>
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>make clean (optional)
>>>>>make
>>>>>make test
>>>>>  
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>The issue with ctest is that is will always "Configure"  and overwrite
>>>>the my DartTestfile.txt generated by the post build command.  Then I get
>>>>an empty list of tests.  I tried the option "--build-nocmake" but
>>>>without any luck.  So, this works:
>>>>
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>make clean
>>>>>ctest -V -D Experimental
>>>>>  
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>But this won't:
>>>>
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>make clean
>>>>>make
>>>>>ctest --build-nocmake -V -D Experimental
>>>>>  
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>It all make sense, but it would be nice to have an option for ctest to
>>>>not regenerate the DartTestfile.txt or at least regenerate only when
>>>>needed (based on changes in CMakeLists.txt or timestamps).  The second
>>>>option would probably work for me since it would also trigger the
>>>>rebuilt and my post build custom command.
>>>>
>>>>Anton
>>>>
>>>>
>>>>On Thu, 2005-06-02 at 09:33, Andy Cedilnik wrote:
>>>>
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>Hi Anton,
>>>>>
>>>>>If you are using CMake, then you will have to know the test names while
>>>>>writing CMakeLists files.
>>>>>
>>>>>I am working on a feature where tests could be added dynamically while
>>>>>running ctest.
>>>>>
>>>>>What you suggested might work, but there may be problems with the way
>>>>>DartTestfile.txt files are traversed.
>>>>>
>>>>>     Andy
>>>>>
>>>>>Anton Deguet wrote:
>>>>>
>>>>>  
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>Hello,
>>>>>>
>>>>>>Now that I have the basics working, I am looking at a way to integrate
>>>>>>our existing test programs with CMake and Dart2.
>>>>>>
>>>>>>We have been using CppUnit and PyUnit for a while to test our libraries
>>>>>>and their SWIG Python wrappers counter-parts.  Our tests are aggregated
>>>>>>in one single executable per library: testProgram.  Then we can use:
>>>>>>
>>>>>>-1- "testProgram -r" run all tests
>>>>>>-2- "testProgram -l" list available tests
>>>>>>-3- "testProgram -r -t oneSpecificTest" to run one test
>>>>>>
>>>>>>I would like to have an entry in the dashboard for each test.  To do so,
>>>>>>I though that I could:
>>>>>>
>>>>>>-1- compile testProgram (ADD_EXECUTABLE() as I already do)
>>>>>>-2- in a post build command, run "testProgram -d" which would produce
>>>>>>its own "DartTestfile.txt" with an "ADD_TEST(testName testProgram -r -t
>>>>>>testName)" for each available test.
>>>>>>-3- Run the tests with ctests
>>>>>>
>>>>>>Is this the right way to go or is there a more orthodox approach?
>>>>>>
>>>>>>Anton
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>    
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>> 
>>>
>>>      
>>>


-- 
Andy Cedilnik
Kitware Inc.