[CMake] Re: [Dart] CMake & Dart2 general design question
Andy Cedilnik
andy.cedilnik at kitware.com
Tue Jun 7 10:01:57 EDT 2005
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.
More information about the CMake
mailing list