Re: [CMake] building tests
[snip] >> >> Ok first thing: I had two cmakes on my system, one was 2.8.1, and an older >> 2.6.3 that snuck in through an incorrect script of mine. >> >> Second thing: the TARGET_FILE thing works. But the usual add_test(name >> command) does not. > > This is because you set the CMAKE_RUNTIME_OUTPUT_DIRECTORY to a location > CMake does not take into account with ADD_TEST( ), but - as > MW already pointed out - ADD_TEST(NAME COMMAND ) works > since this command resolves the executable's path for the target by > itself as $ does, too. > > Typically, ADD_TEST( ) would be used if the test driver is > an external tool, i.e. not part of your project, and located, e.g., by > FIND_PROGRAM(). Nevertheless, CMake looks for it at several familiar > places in case it's still built by the project. The recent signature > ADD_TEST(NAME COMMAND ) is used if the test driver is > actually built by the project, and $ et al. address > the difficulty to predict the location of binaries during the CMake > run when configuring for multi-configuration capable build systems. > > In short: Take "add_test(NAME unit_1 COMMAND unit_1)" for Makefiles or > "add_test(NAME unit_1 COMMAND $)" to be bulletproof. > > Regards, > > Michael Actually, add_test(NAME unit_1 COMMAND unit_1) should always work, even for multi-config IDE's. The $<...> expansion exists if you need to pass the location of the executable as an argument to some driver-script instead of executing it directly. This is often the case for test programs that require environment variables to be set to a specific value or require some special input files to be copied from somewhere, so you create a wrapper script which sets up things and only then executes the test program. Michael ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] building tests
On 07/14/2010 06:40 AM, Paul Harris wrote:
> On 11 July 2010 20:36, Michael Hertling wrote:
>
>> On 07/10/2010 06:54 PM, Paul Harris wrote:
>>> On 9 July 2010 22:39, Michael Wild wrote:
>>>
On 9. Jul, 2010, at 15:48 , Michael Hertling wrote:
> On 07/08/2010 09:47 AM, Paul Harris wrote:
>> On 8 July 2010 15:31, Michael Wild wrote:
>>
>>>
>>> On 8. Jul, 2010, at 7:25 , Paul Harris wrote:
>>>
On 8 July 2010 12:56, Michael Wild wrote:
>
> On 8. Jul, 2010, at 4:40 , Paul Harris wrote:
>
>> On 7 July 2010 23:05, Michael Wild wrote:
>>
>>>
>>> On 7. Jul, 2010, at 16:01 , Paul Harris wrote:
>>>
Hi all,
I have looked and can't find the answer, so I turn to the list.
I have a CMakeLists.txt and a subdirectory called utils, which
also
>>> has
>>> its
own CMakeLists.txt
In the parent CML.txt, I have something like:
ENABLE_TESTING()
add_subdirectory(utils)
In my utils CML.txt, I have
ADD_EXECUTABLE(unit_1 units/unit_1.cpp)
ADD_TEST( unit_1 ${EXECUTABLE_OUTPUT_PATH}/unit_1 )
>>>
>>> Simplify this to
>>>
>>> ADD_TEST(unit_1 unit_1)
>>>
>>> CMake will figure out by itself that unit_1 is a target and
>> invoke
the
>>> executable correctly (your code would break for
>> multi-configuration
>>> IDE
>>> generators).
>>>
>>>
>> This does not work for me. If I do not have the
EXECUTABLE_OUTPUT_PATH
> in
>> add_test, I get a message like this when i run "make test"
(shortened
>>> for
>> brevity):
>>
>> 1/ 1 Testing unit_string_numeric_utils Could not find
executable
>> unit_string_numeric_utils
>> Looked in the following places:
>> unit_string_numeric_utils
>> unit_string_numeric_utils
>> Release/unit_string_numeric_utils
>> Release/unit_string_numeric_utils
>
> Mmmh, works fine for me:
>
> ->8-
> cmake_minimum_required(VERSION 2.8)
> project(tmp)
>
> enable_testing()
>
> add_executable(unit1 unit1.cpp)
> add_test(unit1 unit1)
> -<8-
>
> Where unit1.cpp is just a simple hello-world program. Running it:
>
>
snip
My project is a lot bigger than a hello-world program. It has
subdirectories for a start, and I do things like
SET(EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR}/bin CACHE INTERNAL
>>> "Single
output directory for building all executables.")
I'm not sure at which point things stop working, do you want me to
>> try
>>> and
build a test-case?
>>>
>>> You are right, it seems that the documentation is misleading (or IMHO
>>> outright wrong). This, however, works for me and is safe:
>>>
>>> add_test(NAME unit1 COMMAND $)
>>>
>>> Note that NAME and COMMAND are required for this to work.
>>>
>>> BTW: EXECUTABLE_OUTPUT_PATH is deprecated, you should use
>>> CMAKE_RUNTIME_OUTPUT_DIRECTORY instead.
>>>
>>>
>> I changed EXE to that CMAKE RUNTIME thing, thanks.
>>
>> That NAME/COMMAND thing doesn't work for me at all. Can't find the
binary
>> without the runtime output path explicitly added.
>>
>> This is what I tried:
>>
>> In parent CMakeLists.txt
>>
>> ENABLE_TESTING()
>>
>> set (CMAKE_TEST_COMMAND ctest -V)
>>
>> function (add_unit_test name)
>> if(NOT TARGET ${name})
>> add_custom_target (check COMMAND ${CMAKE_TEST_COMMAND})
>> endif()
>> add_executable(${name} ${ARGN})
>> add_test(NAME ${name} COMMAND $)
>> add_dependencies(check ${name})
>> endfunction()
>>
>>
>> in subdirectory CMakeLists.txt
>> add_unit_test(unit_string_numeric_utils
units/unit_string_numeric_utils.cpp
>> string_numeric_utils.cpp)
>
> Could you detect manually where the binary in question gets written
> to, and post ctest's output with the complaint about not finding it,
> and perhaps you could also post a minimal CMakeLists.txt file which
> demonstrates this issue along with the output of "make VERBOSE=1"?
>
> Regards,
>
> Michael
I suspect he's using a pre-2.8 version of CMake. I confirmed that
>> add_test
only resolves executable target names if used with NAME and COMMAND, and
this signature was introduced in 2.8.
>>> I'm using 2.8.1
>>> Michael Hertling - do you still want me to follow up as you asked?
>>
>> Ye
Re: [CMake] building tests
On 14. Jul, 2010, at 6:40 , Paul Harris wrote:
> On 11 July 2010 20:36, Michael Hertling wrote:
>
>> On 07/10/2010 06:54 PM, Paul Harris wrote:
>>> On 9 July 2010 22:39, Michael Wild wrote:
>>>
On 9. Jul, 2010, at 15:48 , Michael Hertling wrote:
> On 07/08/2010 09:47 AM, Paul Harris wrote:
>> On 8 July 2010 15:31, Michael Wild wrote:
>>
>>>
>>> On 8. Jul, 2010, at 7:25 , Paul Harris wrote:
>>>
On 8 July 2010 12:56, Michael Wild wrote:
>
> On 8. Jul, 2010, at 4:40 , Paul Harris wrote:
>
>> On 7 July 2010 23:05, Michael Wild wrote:
>>
>>>
>>> On 7. Jul, 2010, at 16:01 , Paul Harris wrote:
>>>
Hi all,
I have looked and can't find the answer, so I turn to the list.
I have a CMakeLists.txt and a subdirectory called utils, which
also
>>> has
>>> its
own CMakeLists.txt
In the parent CML.txt, I have something like:
ENABLE_TESTING()
add_subdirectory(utils)
In my utils CML.txt, I have
ADD_EXECUTABLE(unit_1 units/unit_1.cpp)
ADD_TEST( unit_1 ${EXECUTABLE_OUTPUT_PATH}/unit_1 )
>>>
>>> Simplify this to
>>>
>>> ADD_TEST(unit_1 unit_1)
>>>
>>> CMake will figure out by itself that unit_1 is a target and
>> invoke
the
>>> executable correctly (your code would break for
>> multi-configuration
>>> IDE
>>> generators).
>>>
>>>
>> This does not work for me. If I do not have the
EXECUTABLE_OUTPUT_PATH
> in
>> add_test, I get a message like this when i run "make test"
(shortened
>>> for
>> brevity):
>>
>> 1/ 1 Testing unit_string_numeric_utils Could not find
executable
>> unit_string_numeric_utils
>> Looked in the following places:
>> unit_string_numeric_utils
>> unit_string_numeric_utils
>> Release/unit_string_numeric_utils
>> Release/unit_string_numeric_utils
>
> Mmmh, works fine for me:
>
> ->8-
> cmake_minimum_required(VERSION 2.8)
> project(tmp)
>
> enable_testing()
>
> add_executable(unit1 unit1.cpp)
> add_test(unit1 unit1)
> -<8-
>
> Where unit1.cpp is just a simple hello-world program. Running it:
>
>
snip
My project is a lot bigger than a hello-world program. It has
subdirectories for a start, and I do things like
SET(EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR}/bin CACHE INTERNAL
>>> "Single
output directory for building all executables.")
I'm not sure at which point things stop working, do you want me to
>> try
>>> and
build a test-case?
>>>
>>> You are right, it seems that the documentation is misleading (or IMHO
>>> outright wrong). This, however, works for me and is safe:
>>>
>>> add_test(NAME unit1 COMMAND $)
>>>
>>> Note that NAME and COMMAND are required for this to work.
>>>
>>> BTW: EXECUTABLE_OUTPUT_PATH is deprecated, you should use
>>> CMAKE_RUNTIME_OUTPUT_DIRECTORY instead.
>>>
>>>
>> I changed EXE to that CMAKE RUNTIME thing, thanks.
>>
>> That NAME/COMMAND thing doesn't work for me at all. Can't find the
binary
>> without the runtime output path explicitly added.
>>
>> This is what I tried:
>>
>> In parent CMakeLists.txt
>>
>> ENABLE_TESTING()
>>
>> set (CMAKE_TEST_COMMAND ctest -V)
>>
>> function (add_unit_test name)
>> if(NOT TARGET ${name})
>> add_custom_target (check COMMAND ${CMAKE_TEST_COMMAND})
>> endif()
>> add_executable(${name} ${ARGN})
>> add_test(NAME ${name} COMMAND $)
>> add_dependencies(check ${name})
>> endfunction()
>>
>>
>> in subdirectory CMakeLists.txt
>> add_unit_test(unit_string_numeric_utils
units/unit_string_numeric_utils.cpp
>> string_numeric_utils.cpp)
>
> Could you detect manually where the binary in question gets written
> to, and post ctest's output with the complaint about not finding it,
> and perhaps you could also post a minimal CMakeLists.txt file which
> demonstrates this issue along with the output of "make VERBOSE=1"?
>
> Regards,
>
> Michael
I suspect he's using a pre-2.8 version of CMake. I confirmed that
>> add_test
only resolves executable target names if used with NAME and COMMAND, and
this signature was introduced in 2.8.
>>> I'm using 2.8.1
>>> Michael Hertling - do
Re: [CMake] building tests
On 11 July 2010 20:36, Michael Hertling wrote:
> On 07/10/2010 06:54 PM, Paul Harris wrote:
> > On 9 July 2010 22:39, Michael Wild wrote:
> >
> >>
> >> On 9. Jul, 2010, at 15:48 , Michael Hertling wrote:
> >>
> >>> On 07/08/2010 09:47 AM, Paul Harris wrote:
> On 8 July 2010 15:31, Michael Wild wrote:
>
> >
> > On 8. Jul, 2010, at 7:25 , Paul Harris wrote:
> >
> >> On 8 July 2010 12:56, Michael Wild wrote:
> >>
> >>>
> >>> On 8. Jul, 2010, at 4:40 , Paul Harris wrote:
> >>>
> On 7 July 2010 23:05, Michael Wild wrote:
>
> >
> > On 7. Jul, 2010, at 16:01 , Paul Harris wrote:
> >
> >> Hi all,
> >>
> >> I have looked and can't find the answer, so I turn to the list.
> >>
> >> I have a CMakeLists.txt and a subdirectory called utils, which
> >> also
> > has
> > its
> >> own CMakeLists.txt
> >>
> >> In the parent CML.txt, I have something like:
> >>
> >> ENABLE_TESTING()
> >> add_subdirectory(utils)
> >>
> >> In my utils CML.txt, I have
> >>
> >> ADD_EXECUTABLE(unit_1 units/unit_1.cpp)
> >> ADD_TEST( unit_1 ${EXECUTABLE_OUTPUT_PATH}/unit_1 )
> >>
> >
> > Simplify this to
> >
> > ADD_TEST(unit_1 unit_1)
> >
> > CMake will figure out by itself that unit_1 is a target and
> invoke
> >> the
> > executable correctly (your code would break for
> multi-configuration
> > IDE
> > generators).
> >
> >
> This does not work for me. If I do not have the
> >> EXECUTABLE_OUTPUT_PATH
> >>> in
> add_test, I get a message like this when i run "make test"
> >> (shortened
> > for
> brevity):
>
> 1/ 1 Testing unit_string_numeric_utils Could not find
> >> executable
> unit_string_numeric_utils
> Looked in the following places:
> unit_string_numeric_utils
> unit_string_numeric_utils
> Release/unit_string_numeric_utils
> Release/unit_string_numeric_utils
> >>>
> >>> Mmmh, works fine for me:
> >>>
> >>> ->8-
> >>> cmake_minimum_required(VERSION 2.8)
> >>> project(tmp)
> >>>
> >>> enable_testing()
> >>>
> >>> add_executable(unit1 unit1.cpp)
> >>> add_test(unit1 unit1)
> >>> -<8-
> >>>
> >>> Where unit1.cpp is just a simple hello-world program. Running it:
> >>>
> >>>
> >> snip
> >>
> >> My project is a lot bigger than a hello-world program. It has
> >> subdirectories for a start, and I do things like
> >> SET(EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR}/bin CACHE INTERNAL
> > "Single
> >> output directory for building all executables.")
> >>
> >> I'm not sure at which point things stop working, do you want me to
> try
> > and
> >> build a test-case?
> >
> > You are right, it seems that the documentation is misleading (or IMHO
> > outright wrong). This, however, works for me and is safe:
> >
> > add_test(NAME unit1 COMMAND $)
> >
> > Note that NAME and COMMAND are required for this to work.
> >
> > BTW: EXECUTABLE_OUTPUT_PATH is deprecated, you should use
> > CMAKE_RUNTIME_OUTPUT_DIRECTORY instead.
> >
> >
> I changed EXE to that CMAKE RUNTIME thing, thanks.
>
> That NAME/COMMAND thing doesn't work for me at all. Can't find the
> >> binary
> without the runtime output path explicitly added.
>
> This is what I tried:
>
> In parent CMakeLists.txt
>
> ENABLE_TESTING()
>
> set (CMAKE_TEST_COMMAND ctest -V)
>
> function (add_unit_test name)
> if(NOT TARGET ${name})
> add_custom_target (check COMMAND ${CMAKE_TEST_COMMAND})
> endif()
> add_executable(${name} ${ARGN})
> add_test(NAME ${name} COMMAND $)
> add_dependencies(check ${name})
> endfunction()
>
>
> in subdirectory CMakeLists.txt
> add_unit_test(unit_string_numeric_utils
> >> units/unit_string_numeric_utils.cpp
> string_numeric_utils.cpp)
> >>>
> >>> Could you detect manually where the binary in question gets written
> >>> to, and post ctest's output with the complaint about not finding it,
> >>> and perhaps you could also post a minimal CMakeLists.txt file which
> >>> demonstrates this issue along with the output of "make VERBOSE=1"?
> >>>
> >>> Regards,
> >>>
> >>> Michael
> >>
> >> I suspect he's using a pre-2.8 version of CMake. I confirmed that
> add_test
> >> only resolves executable target names if used with NAME and COMMAND, and
> >> this signature was introduced in 2.8.
> >>
> >>
> > I'm using 2.8.1
> > Michael Hertling - do you still want me to follow up as you asked?
>
> Yes, of course, if the problem still persists. Until now
Re: [CMake] building tests
On 07/10/2010 06:54 PM, Paul Harris wrote:
> On 9 July 2010 22:39, Michael Wild wrote:
>
>>
>> On 9. Jul, 2010, at 15:48 , Michael Hertling wrote:
>>
>>> On 07/08/2010 09:47 AM, Paul Harris wrote:
On 8 July 2010 15:31, Michael Wild wrote:
>
> On 8. Jul, 2010, at 7:25 , Paul Harris wrote:
>
>> On 8 July 2010 12:56, Michael Wild wrote:
>>
>>>
>>> On 8. Jul, 2010, at 4:40 , Paul Harris wrote:
>>>
On 7 July 2010 23:05, Michael Wild wrote:
>
> On 7. Jul, 2010, at 16:01 , Paul Harris wrote:
>
>> Hi all,
>>
>> I have looked and can't find the answer, so I turn to the list.
>>
>> I have a CMakeLists.txt and a subdirectory called utils, which
>> also
> has
> its
>> own CMakeLists.txt
>>
>> In the parent CML.txt, I have something like:
>>
>> ENABLE_TESTING()
>> add_subdirectory(utils)
>>
>> In my utils CML.txt, I have
>>
>> ADD_EXECUTABLE(unit_1 units/unit_1.cpp)
>> ADD_TEST( unit_1 ${EXECUTABLE_OUTPUT_PATH}/unit_1 )
>>
>
> Simplify this to
>
> ADD_TEST(unit_1 unit_1)
>
> CMake will figure out by itself that unit_1 is a target and invoke
>> the
> executable correctly (your code would break for multi-configuration
> IDE
> generators).
>
>
This does not work for me. If I do not have the
>> EXECUTABLE_OUTPUT_PATH
>>> in
add_test, I get a message like this when i run "make test"
>> (shortened
> for
brevity):
1/ 1 Testing unit_string_numeric_utils Could not find
>> executable
unit_string_numeric_utils
Looked in the following places:
unit_string_numeric_utils
unit_string_numeric_utils
Release/unit_string_numeric_utils
Release/unit_string_numeric_utils
>>>
>>> Mmmh, works fine for me:
>>>
>>> ->8-
>>> cmake_minimum_required(VERSION 2.8)
>>> project(tmp)
>>>
>>> enable_testing()
>>>
>>> add_executable(unit1 unit1.cpp)
>>> add_test(unit1 unit1)
>>> -<8-
>>>
>>> Where unit1.cpp is just a simple hello-world program. Running it:
>>>
>>>
>> snip
>>
>> My project is a lot bigger than a hello-world program. It has
>> subdirectories for a start, and I do things like
>> SET(EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR}/bin CACHE INTERNAL
> "Single
>> output directory for building all executables.")
>>
>> I'm not sure at which point things stop working, do you want me to try
> and
>> build a test-case?
>
> You are right, it seems that the documentation is misleading (or IMHO
> outright wrong). This, however, works for me and is safe:
>
> add_test(NAME unit1 COMMAND $)
>
> Note that NAME and COMMAND are required for this to work.
>
> BTW: EXECUTABLE_OUTPUT_PATH is deprecated, you should use
> CMAKE_RUNTIME_OUTPUT_DIRECTORY instead.
>
>
I changed EXE to that CMAKE RUNTIME thing, thanks.
That NAME/COMMAND thing doesn't work for me at all. Can't find the
>> binary
without the runtime output path explicitly added.
This is what I tried:
In parent CMakeLists.txt
ENABLE_TESTING()
set (CMAKE_TEST_COMMAND ctest -V)
function (add_unit_test name)
if(NOT TARGET ${name})
add_custom_target (check COMMAND ${CMAKE_TEST_COMMAND})
endif()
add_executable(${name} ${ARGN})
add_test(NAME ${name} COMMAND $)
add_dependencies(check ${name})
endfunction()
in subdirectory CMakeLists.txt
add_unit_test(unit_string_numeric_utils
>> units/unit_string_numeric_utils.cpp
string_numeric_utils.cpp)
>>>
>>> Could you detect manually where the binary in question gets written
>>> to, and post ctest's output with the complaint about not finding it,
>>> and perhaps you could also post a minimal CMakeLists.txt file which
>>> demonstrates this issue along with the output of "make VERBOSE=1"?
>>>
>>> Regards,
>>>
>>> Michael
>>
>> I suspect he's using a pre-2.8 version of CMake. I confirmed that add_test
>> only resolves executable target names if used with NAME and COMMAND, and
>> this signature was introduced in 2.8.
>>
>>
> I'm using 2.8.1
> Michael Hertling - do you still want me to follow up as you asked?
Yes, of course, if the problem still persists. Until now, I haven't
managed to let CTest miss an executable previously built by CMake,
i.e. ADD_TEST(NAME ... COMMAND ...) always worked well for me.
Regards,
Michael
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and
Re: [CMake] building tests
On 9 July 2010 22:39, Michael Wild wrote:
>
> On 9. Jul, 2010, at 15:48 , Michael Hertling wrote:
>
> > On 07/08/2010 09:47 AM, Paul Harris wrote:
> >> On 8 July 2010 15:31, Michael Wild wrote:
> >>
> >>>
> >>> On 8. Jul, 2010, at 7:25 , Paul Harris wrote:
> >>>
> On 8 July 2010 12:56, Michael Wild wrote:
>
> >
> > On 8. Jul, 2010, at 4:40 , Paul Harris wrote:
> >
> >> On 7 July 2010 23:05, Michael Wild wrote:
> >>
> >>>
> >>> On 7. Jul, 2010, at 16:01 , Paul Harris wrote:
> >>>
> Hi all,
>
> I have looked and can't find the answer, so I turn to the list.
>
> I have a CMakeLists.txt and a subdirectory called utils, which
> also
> >>> has
> >>> its
> own CMakeLists.txt
>
> In the parent CML.txt, I have something like:
>
> ENABLE_TESTING()
> add_subdirectory(utils)
>
> In my utils CML.txt, I have
>
> ADD_EXECUTABLE(unit_1 units/unit_1.cpp)
> ADD_TEST( unit_1 ${EXECUTABLE_OUTPUT_PATH}/unit_1 )
>
> >>>
> >>> Simplify this to
> >>>
> >>> ADD_TEST(unit_1 unit_1)
> >>>
> >>> CMake will figure out by itself that unit_1 is a target and invoke
> the
> >>> executable correctly (your code would break for multi-configuration
> >>> IDE
> >>> generators).
> >>>
> >>>
> >> This does not work for me. If I do not have the
> EXECUTABLE_OUTPUT_PATH
> > in
> >> add_test, I get a message like this when i run "make test"
> (shortened
> >>> for
> >> brevity):
> >>
> >> 1/ 1 Testing unit_string_numeric_utils Could not find
> executable
> >> unit_string_numeric_utils
> >> Looked in the following places:
> >> unit_string_numeric_utils
> >> unit_string_numeric_utils
> >> Release/unit_string_numeric_utils
> >> Release/unit_string_numeric_utils
> >
> > Mmmh, works fine for me:
> >
> > ->8-
> > cmake_minimum_required(VERSION 2.8)
> > project(tmp)
> >
> > enable_testing()
> >
> > add_executable(unit1 unit1.cpp)
> > add_test(unit1 unit1)
> > -<8-
> >
> > Where unit1.cpp is just a simple hello-world program. Running it:
> >
> >
> snip
>
> My project is a lot bigger than a hello-world program. It has
> subdirectories for a start, and I do things like
> SET(EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR}/bin CACHE INTERNAL
> >>> "Single
> output directory for building all executables.")
>
> I'm not sure at which point things stop working, do you want me to try
> >>> and
> build a test-case?
> >>>
> >>> You are right, it seems that the documentation is misleading (or IMHO
> >>> outright wrong). This, however, works for me and is safe:
> >>>
> >>> add_test(NAME unit1 COMMAND $)
> >>>
> >>> Note that NAME and COMMAND are required for this to work.
> >>>
> >>> BTW: EXECUTABLE_OUTPUT_PATH is deprecated, you should use
> >>> CMAKE_RUNTIME_OUTPUT_DIRECTORY instead.
> >>>
> >>>
> >> I changed EXE to that CMAKE RUNTIME thing, thanks.
> >>
> >> That NAME/COMMAND thing doesn't work for me at all. Can't find the
> binary
> >> without the runtime output path explicitly added.
> >>
> >> This is what I tried:
> >>
> >> In parent CMakeLists.txt
> >>
> >> ENABLE_TESTING()
> >>
> >> set (CMAKE_TEST_COMMAND ctest -V)
> >>
> >> function (add_unit_test name)
> >> if(NOT TARGET ${name})
> >> add_custom_target (check COMMAND ${CMAKE_TEST_COMMAND})
> >> endif()
> >> add_executable(${name} ${ARGN})
> >> add_test(NAME ${name} COMMAND $)
> >> add_dependencies(check ${name})
> >> endfunction()
> >>
> >>
> >> in subdirectory CMakeLists.txt
> >> add_unit_test(unit_string_numeric_utils
> units/unit_string_numeric_utils.cpp
> >> string_numeric_utils.cpp)
> >
> > Could you detect manually where the binary in question gets written
> > to, and post ctest's output with the complaint about not finding it,
> > and perhaps you could also post a minimal CMakeLists.txt file which
> > demonstrates this issue along with the output of "make VERBOSE=1"?
> >
> > Regards,
> >
> > Michael
>
> I suspect he's using a pre-2.8 version of CMake. I confirmed that add_test
> only resolves executable target names if used with NAME and COMMAND, and
> this signature was introduced in 2.8.
>
>
I'm using 2.8.1
Michael Hertling - do you still want me to follow up as you asked?
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] building tests
On 9. Jul, 2010, at 15:48 , Michael Hertling wrote:
> On 07/08/2010 09:47 AM, Paul Harris wrote:
>> On 8 July 2010 15:31, Michael Wild wrote:
>>
>>>
>>> On 8. Jul, 2010, at 7:25 , Paul Harris wrote:
>>>
On 8 July 2010 12:56, Michael Wild wrote:
>
> On 8. Jul, 2010, at 4:40 , Paul Harris wrote:
>
>> On 7 July 2010 23:05, Michael Wild wrote:
>>
>>>
>>> On 7. Jul, 2010, at 16:01 , Paul Harris wrote:
>>>
Hi all,
I have looked and can't find the answer, so I turn to the list.
I have a CMakeLists.txt and a subdirectory called utils, which also
>>> has
>>> its
own CMakeLists.txt
In the parent CML.txt, I have something like:
ENABLE_TESTING()
add_subdirectory(utils)
In my utils CML.txt, I have
ADD_EXECUTABLE(unit_1 units/unit_1.cpp)
ADD_TEST( unit_1 ${EXECUTABLE_OUTPUT_PATH}/unit_1 )
>>>
>>> Simplify this to
>>>
>>> ADD_TEST(unit_1 unit_1)
>>>
>>> CMake will figure out by itself that unit_1 is a target and invoke the
>>> executable correctly (your code would break for multi-configuration
>>> IDE
>>> generators).
>>>
>>>
>> This does not work for me. If I do not have the EXECUTABLE_OUTPUT_PATH
> in
>> add_test, I get a message like this when i run "make test" (shortened
>>> for
>> brevity):
>>
>> 1/ 1 Testing unit_string_numeric_utils Could not find executable
>> unit_string_numeric_utils
>> Looked in the following places:
>> unit_string_numeric_utils
>> unit_string_numeric_utils
>> Release/unit_string_numeric_utils
>> Release/unit_string_numeric_utils
>
> Mmmh, works fine for me:
>
> ->8-
> cmake_minimum_required(VERSION 2.8)
> project(tmp)
>
> enable_testing()
>
> add_executable(unit1 unit1.cpp)
> add_test(unit1 unit1)
> -<8-
>
> Where unit1.cpp is just a simple hello-world program. Running it:
>
>
snip
My project is a lot bigger than a hello-world program. It has
subdirectories for a start, and I do things like
SET(EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR}/bin CACHE INTERNAL
>>> "Single
output directory for building all executables.")
I'm not sure at which point things stop working, do you want me to try
>>> and
build a test-case?
>>>
>>> You are right, it seems that the documentation is misleading (or IMHO
>>> outright wrong). This, however, works for me and is safe:
>>>
>>> add_test(NAME unit1 COMMAND $)
>>>
>>> Note that NAME and COMMAND are required for this to work.
>>>
>>> BTW: EXECUTABLE_OUTPUT_PATH is deprecated, you should use
>>> CMAKE_RUNTIME_OUTPUT_DIRECTORY instead.
>>>
>>>
>> I changed EXE to that CMAKE RUNTIME thing, thanks.
>>
>> That NAME/COMMAND thing doesn't work for me at all. Can't find the binary
>> without the runtime output path explicitly added.
>>
>> This is what I tried:
>>
>> In parent CMakeLists.txt
>>
>> ENABLE_TESTING()
>>
>> set (CMAKE_TEST_COMMAND ctest -V)
>>
>> function (add_unit_test name)
>> if(NOT TARGET ${name})
>> add_custom_target (check COMMAND ${CMAKE_TEST_COMMAND})
>> endif()
>> add_executable(${name} ${ARGN})
>> add_test(NAME ${name} COMMAND $)
>> add_dependencies(check ${name})
>> endfunction()
>>
>>
>> in subdirectory CMakeLists.txt
>> add_unit_test(unit_string_numeric_utils units/unit_string_numeric_utils.cpp
>> string_numeric_utils.cpp)
>
> Could you detect manually where the binary in question gets written
> to, and post ctest's output with the complaint about not finding it,
> and perhaps you could also post a minimal CMakeLists.txt file which
> demonstrates this issue along with the output of "make VERBOSE=1"?
>
> Regards,
>
> Michael
I suspect he's using a pre-2.8 version of CMake. I confirmed that add_test only
resolves executable target names if used with NAME and COMMAND, and this
signature was introduced in 2.8.
Michael
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] building tests
On 07/08/2010 09:47 AM, Paul Harris wrote:
> On 8 July 2010 15:31, Michael Wild wrote:
>
>>
>> On 8. Jul, 2010, at 7:25 , Paul Harris wrote:
>>
>>> On 8 July 2010 12:56, Michael Wild wrote:
>>>
On 8. Jul, 2010, at 4:40 , Paul Harris wrote:
> On 7 July 2010 23:05, Michael Wild wrote:
>
>>
>> On 7. Jul, 2010, at 16:01 , Paul Harris wrote:
>>
>>> Hi all,
>>>
>>> I have looked and can't find the answer, so I turn to the list.
>>>
>>> I have a CMakeLists.txt and a subdirectory called utils, which also
>> has
>> its
>>> own CMakeLists.txt
>>>
>>> In the parent CML.txt, I have something like:
>>>
>>> ENABLE_TESTING()
>>> add_subdirectory(utils)
>>>
>>> In my utils CML.txt, I have
>>>
>>> ADD_EXECUTABLE(unit_1 units/unit_1.cpp)
>>> ADD_TEST( unit_1 ${EXECUTABLE_OUTPUT_PATH}/unit_1 )
>>>
>>
>> Simplify this to
>>
>> ADD_TEST(unit_1 unit_1)
>>
>> CMake will figure out by itself that unit_1 is a target and invoke the
>> executable correctly (your code would break for multi-configuration
>> IDE
>> generators).
>>
>>
> This does not work for me. If I do not have the EXECUTABLE_OUTPUT_PATH
in
> add_test, I get a message like this when i run "make test" (shortened
>> for
> brevity):
>
> 1/ 1 Testing unit_string_numeric_utils Could not find executable
> unit_string_numeric_utils
> Looked in the following places:
> unit_string_numeric_utils
> unit_string_numeric_utils
> Release/unit_string_numeric_utils
> Release/unit_string_numeric_utils
Mmmh, works fine for me:
->8-
cmake_minimum_required(VERSION 2.8)
project(tmp)
enable_testing()
add_executable(unit1 unit1.cpp)
add_test(unit1 unit1)
-<8-
Where unit1.cpp is just a simple hello-world program. Running it:
>>> snip
>>>
>>> My project is a lot bigger than a hello-world program. It has
>>> subdirectories for a start, and I do things like
>>> SET(EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR}/bin CACHE INTERNAL
>> "Single
>>> output directory for building all executables.")
>>>
>>> I'm not sure at which point things stop working, do you want me to try
>> and
>>> build a test-case?
>>
>> You are right, it seems that the documentation is misleading (or IMHO
>> outright wrong). This, however, works for me and is safe:
>>
>> add_test(NAME unit1 COMMAND $)
>>
>> Note that NAME and COMMAND are required for this to work.
>>
>> BTW: EXECUTABLE_OUTPUT_PATH is deprecated, you should use
>> CMAKE_RUNTIME_OUTPUT_DIRECTORY instead.
>>
>>
> I changed EXE to that CMAKE RUNTIME thing, thanks.
>
> That NAME/COMMAND thing doesn't work for me at all. Can't find the binary
> without the runtime output path explicitly added.
>
> This is what I tried:
>
> In parent CMakeLists.txt
>
> ENABLE_TESTING()
>
> set (CMAKE_TEST_COMMAND ctest -V)
>
> function (add_unit_test name)
>if(NOT TARGET ${name})
> add_custom_target (check COMMAND ${CMAKE_TEST_COMMAND})
>endif()
>add_executable(${name} ${ARGN})
>add_test(NAME ${name} COMMAND $)
>add_dependencies(check ${name})
> endfunction()
>
>
> in subdirectory CMakeLists.txt
> add_unit_test(unit_string_numeric_utils units/unit_string_numeric_utils.cpp
> string_numeric_utils.cpp)
Could you detect manually where the binary in question gets written
to, and post ctest's output with the complaint about not finding it,
and perhaps you could also post a minimal CMakeLists.txt file which
demonstrates this issue along with the output of "make VERBOSE=1"?
Regards,
Michael
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] building tests
On Thu, 2010-07-08 at 16:30 +0800, Paul Harris wrote:
>
>
> On 8 July 2010 16:27, Marcel Loose wrote:
>
> On Thu, 2010-07-08 at 11:12 +0800, Paul Harris wrote:
> >
> >
> > On 7 July 2010 23:38, Marcel Loose wrote:
> >
> > On Wed, 2010-07-07 at 17:05 +0200, Michael Wild
> wrote:
> > > On 7. Jul, 2010, at 16:01 , Paul Harris wrote:
> > >
> > > > Hi all,
> > > >
> > > > I have looked and can't find the answer, so I
> turn to the
> > list.
> > > >
> > > > I have a CMakeLists.txt and a subdirectory
> called utils,
> > which also
> > has its
> > > > own CMakeLists.txt
> > > >
> > > > In the parent CML.txt, I have something like:
> > > >
> > > > ENABLE_TESTING()
> > > > add_subdirectory(utils)
> > > >
> > > > In my utils CML.txt, I have
> > > >
> > > > ADD_EXECUTABLE(unit_1 units/unit_1.cpp)
> > > > ADD_TEST( unit_1
> ${EXECUTABLE_OUTPUT_PATH}/unit_1 )
> > > >
> > >
> > > Simplify this to
> > >
> > > ADD_TEST(unit_1 unit_1)
> > >
> > > CMake will figure out by itself that unit_1 is a
> target and
> > invoke the
> > executable correctly (your code would break for
> > multi-configuration IDE
> > generators).
> > >
> > > As for the dependencies, I agree that it would be
> nice if
> > the "test"
> > target depended on the executables. But what is
> wrong with
> > "make all
> > test" (apart from the fact that it possibly compiles
> more than
> > you
> > actually need to run the test)? You could also wrap
> the
> > add_executable
> > call in a custom function which creates a custom
> target (say
> > test_exes)
> > and makes it depend on all the executables:
> > >
> > > function(add_test_executable name)
> > > if(NOT TARGET ${name})
> > > add_custom_target(test_exes)
> > >endif()
> > >add_executable(${name} ${ARGN})
> > >add_dependencies(test_exes ${name})
> > > endfunction()
> > >
> > > Then you can do "make test_exes test".
> > >
> > > HTH
> > >
> > > Michael
> >
> >
> > You can further reduce the number of targets that
> get
> > (re)build by going
> > into the directory '${CMAKE_BINARY_DIR}/utils' and
> invoke
> > 'make' there.
> >
> > You could also define a 'check' target that will
> build and run
> > all your
> > test programs. See
> > http://www.cmake.org/Wiki/CMakeEmulateMakeCheck
> >
> > Best regards,
> > Marcel Loose.
> >
> >
> > Thanks Marcel, I combined the solution in the wiki with what
> was
> > discussed in my last email, and I ended up with
> >
> > set (CMAKE_TEST_COMMAND "ctest")
> >
> > function (add_unit_test name)
> >if(NOT TARGET ${name})
> > add_custom_target (check COMMAND
> ${CMAKE_TEST_COMMAND})
> >endif()
> >add_executable(${name} ${ARGN})
> ># or ADD_EXECUTABLE(${name} ${ARGN} EXCLUDE_FROM_ALL)
> >#if you want it to be skipped when building 'all'
> >add_test(${name} ${EXECUTABLE_OUTPUT_PATH}/${name})
> >add_dependencies(check ${name})
> > endfunction()
> >
> >
> >
> > however, I have discovered (with message()) that
> ${CMAKE_TEST_COMMAND}
> > is *empty* - its something I had to set(), which is not
> mentioned in
> > the wiki page you mentioned. It IS kind-of-mentioned in
> "Cmake
> > Scripting of CTest" but not explicitly enough to catch the
> eye.
> >
> > I've edited the wiki page, please check that my edits make
> sense.
> >
> > Thanks
> > Paul
>
> Hi Paul,
>
>
> While re-reading you add_unit_test function above I was
> wondering
>
Re: [CMake] building tests
On Thu, 2010-07-08 at 11:12 +0800, Paul Harris wrote:
>
>
> On 7 July 2010 23:38, Marcel Loose wrote:
>
> On Wed, 2010-07-07 at 17:05 +0200, Michael Wild wrote:
> > On 7. Jul, 2010, at 16:01 , Paul Harris wrote:
> >
> > > Hi all,
> > >
> > > I have looked and can't find the answer, so I turn to the
> list.
> > >
> > > I have a CMakeLists.txt and a subdirectory called utils,
> which also
> has its
> > > own CMakeLists.txt
> > >
> > > In the parent CML.txt, I have something like:
> > >
> > > ENABLE_TESTING()
> > > add_subdirectory(utils)
> > >
> > > In my utils CML.txt, I have
> > >
> > > ADD_EXECUTABLE(unit_1 units/unit_1.cpp)
> > > ADD_TEST( unit_1 ${EXECUTABLE_OUTPUT_PATH}/unit_1 )
> > >
> >
> > Simplify this to
> >
> > ADD_TEST(unit_1 unit_1)
> >
> > CMake will figure out by itself that unit_1 is a target and
> invoke the
> executable correctly (your code would break for
> multi-configuration IDE
> generators).
> >
> > As for the dependencies, I agree that it would be nice if
> the "test"
> target depended on the executables. But what is wrong with
> "make all
> test" (apart from the fact that it possibly compiles more than
> you
> actually need to run the test)? You could also wrap the
> add_executable
> call in a custom function which creates a custom target (say
> test_exes)
> and makes it depend on all the executables:
> >
> > function(add_test_executable name)
> > if(NOT TARGET ${name})
> > add_custom_target(test_exes)
> >endif()
> >add_executable(${name} ${ARGN})
> >add_dependencies(test_exes ${name})
> > endfunction()
> >
> > Then you can do "make test_exes test".
> >
> > HTH
> >
> > Michael
>
>
> You can further reduce the number of targets that get
> (re)build by going
> into the directory '${CMAKE_BINARY_DIR}/utils' and invoke
> 'make' there.
>
> You could also define a 'check' target that will build and run
> all your
> test programs. See
> http://www.cmake.org/Wiki/CMakeEmulateMakeCheck
>
> Best regards,
> Marcel Loose.
>
>
> Thanks Marcel, I combined the solution in the wiki with what was
> discussed in my last email, and I ended up with
>
> set (CMAKE_TEST_COMMAND "ctest")
>
> function (add_unit_test name)
>if(NOT TARGET ${name})
> add_custom_target (check COMMAND ${CMAKE_TEST_COMMAND})
>endif()
>add_executable(${name} ${ARGN})
># or ADD_EXECUTABLE(${name} ${ARGN} EXCLUDE_FROM_ALL)
>#if you want it to be skipped when building 'all'
>add_test(${name} ${EXECUTABLE_OUTPUT_PATH}/${name})
>add_dependencies(check ${name})
> endfunction()
>
>
>
> however, I have discovered (with message()) that ${CMAKE_TEST_COMMAND}
> is *empty* - its something I had to set(), which is not mentioned in
> the wiki page you mentioned. It IS kind-of-mentioned in "Cmake
> Scripting of CTest" but not explicitly enough to catch the eye.
>
> I've edited the wiki page, please check that my edits make sense.
>
> Thanks
> Paul
Hi Paul,
While re-reading you add_unit_test function above I was wondering
whether this will actually work. The snippet
if(NOT TARGET ${name})
add_custom_target (check COMMAND ${CMAKE_TEST_COMMAND})
endif()
strikes me as odd. This will cause multiple definitions of the 'check'
target, which is not allowed, unless you set a policy (don't know by
heart which one exactly). Anyway, multiple definitions of the same
target are only supported by Unix Makefiles; I don't think you want to
restrict yourself unnecessarily.
Best regards,
Marcel Loose.
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] building tests
On Thu, 2010-07-08 at 11:12 +0800, Paul Harris wrote:
>
>
> On 7 July 2010 23:38, Marcel Loose wrote:
>
> On Wed, 2010-07-07 at 17:05 +0200, Michael Wild wrote:
> > On 7. Jul, 2010, at 16:01 , Paul Harris wrote:
> >
> > > Hi all,
> > >
> > > I have looked and can't find the answer, so I turn to the
> list.
> > >
> > > I have a CMakeLists.txt and a subdirectory called utils,
> which also
> has its
> > > own CMakeLists.txt
> > >
> > > In the parent CML.txt, I have something like:
> > >
> > > ENABLE_TESTING()
> > > add_subdirectory(utils)
> > >
> > > In my utils CML.txt, I have
> > >
> > > ADD_EXECUTABLE(unit_1 units/unit_1.cpp)
> > > ADD_TEST( unit_1 ${EXECUTABLE_OUTPUT_PATH}/unit_1 )
> > >
> >
> > Simplify this to
> >
> > ADD_TEST(unit_1 unit_1)
> >
> > CMake will figure out by itself that unit_1 is a target and
> invoke the
> executable correctly (your code would break for
> multi-configuration IDE
> generators).
> >
> > As for the dependencies, I agree that it would be nice if
> the "test"
> target depended on the executables. But what is wrong with
> "make all
> test" (apart from the fact that it possibly compiles more than
> you
> actually need to run the test)? You could also wrap the
> add_executable
> call in a custom function which creates a custom target (say
> test_exes)
> and makes it depend on all the executables:
> >
> > function(add_test_executable name)
> > if(NOT TARGET ${name})
> > add_custom_target(test_exes)
> >endif()
> >add_executable(${name} ${ARGN})
> >add_dependencies(test_exes ${name})
> > endfunction()
> >
> > Then you can do "make test_exes test".
> >
> > HTH
> >
> > Michael
>
>
> You can further reduce the number of targets that get
> (re)build by going
> into the directory '${CMAKE_BINARY_DIR}/utils' and invoke
> 'make' there.
>
> You could also define a 'check' target that will build and run
> all your
> test programs. See
> http://www.cmake.org/Wiki/CMakeEmulateMakeCheck
>
> Best regards,
> Marcel Loose.
>
>
> Thanks Marcel, I combined the solution in the wiki with what was
> discussed in my last email, and I ended up with
>
> set (CMAKE_TEST_COMMAND "ctest")
>
> function (add_unit_test name)
>if(NOT TARGET ${name})
> add_custom_target (check COMMAND ${CMAKE_TEST_COMMAND})
>endif()
>add_executable(${name} ${ARGN})
># or ADD_EXECUTABLE(${name} ${ARGN} EXCLUDE_FROM_ALL)
>#if you want it to be skipped when building 'all'
>add_test(${name} ${EXECUTABLE_OUTPUT_PATH}/${name})
>add_dependencies(check ${name})
> endfunction()
>
>
>
> however, I have discovered (with message()) that ${CMAKE_TEST_COMMAND}
> is *empty* - its something I had to set(), which is not mentioned in
> the wiki page you mentioned. It IS kind-of-mentioned in "Cmake
> Scripting of CTest" but not explicitly enough to catch the eye.
>
> I've edited the wiki page, please check that my edits make sense.
>
> Thanks
> Paul
Hi Paul,
I'm sorry to say that I think your edits do not make sense.
The problem is that you missed one letter in the variable name that is
definitely present in the wiki example.
CMAKE_TEST_COMMAND does not exist, so yes indeed, you have to set it
yourself.
CMAKE_CTEST_COMMAND, on the other hand, is set by CMake and should
*always* be used if you want to run ctest, because it guarantees that
you're using the same ctest when running the tests as when cmake was
configuring your makefiles (or VS build files, etc.).
If the original wiki page was not clear enough, please feel free to
change things, but the current changes do not make sense.
Best regards,
Marcel Loose.
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] building tests
On 8 July 2010 15:31, Michael Wild wrote:
>
> On 8. Jul, 2010, at 7:25 , Paul Harris wrote:
>
> > On 8 July 2010 12:56, Michael Wild wrote:
> >
> >>
> >> On 8. Jul, 2010, at 4:40 , Paul Harris wrote:
> >>
> >>> On 7 July 2010 23:05, Michael Wild wrote:
> >>>
>
> On 7. Jul, 2010, at 16:01 , Paul Harris wrote:
>
> > Hi all,
> >
> > I have looked and can't find the answer, so I turn to the list.
> >
> > I have a CMakeLists.txt and a subdirectory called utils, which also
> has
> its
> > own CMakeLists.txt
> >
> > In the parent CML.txt, I have something like:
> >
> > ENABLE_TESTING()
> > add_subdirectory(utils)
> >
> > In my utils CML.txt, I have
> >
> > ADD_EXECUTABLE(unit_1 units/unit_1.cpp)
> > ADD_TEST( unit_1 ${EXECUTABLE_OUTPUT_PATH}/unit_1 )
> >
>
> Simplify this to
>
> ADD_TEST(unit_1 unit_1)
>
> CMake will figure out by itself that unit_1 is a target and invoke the
> executable correctly (your code would break for multi-configuration
> IDE
> generators).
>
>
> >>> This does not work for me. If I do not have the EXECUTABLE_OUTPUT_PATH
> >> in
> >>> add_test, I get a message like this when i run "make test" (shortened
> for
> >>> brevity):
> >>>
> >>> 1/ 1 Testing unit_string_numeric_utils Could not find executable
> >>> unit_string_numeric_utils
> >>> Looked in the following places:
> >>> unit_string_numeric_utils
> >>> unit_string_numeric_utils
> >>> Release/unit_string_numeric_utils
> >>> Release/unit_string_numeric_utils
> >>
> >> Mmmh, works fine for me:
> >>
> >> ->8-
> >> cmake_minimum_required(VERSION 2.8)
> >> project(tmp)
> >>
> >> enable_testing()
> >>
> >> add_executable(unit1 unit1.cpp)
> >> add_test(unit1 unit1)
> >> -<8-
> >>
> >> Where unit1.cpp is just a simple hello-world program. Running it:
> >>
> >>
> > snip
> >
> > My project is a lot bigger than a hello-world program. It has
> > subdirectories for a start, and I do things like
> > SET(EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR}/bin CACHE INTERNAL
> "Single
> > output directory for building all executables.")
> >
> > I'm not sure at which point things stop working, do you want me to try
> and
> > build a test-case?
>
> You are right, it seems that the documentation is misleading (or IMHO
> outright wrong). This, however, works for me and is safe:
>
> add_test(NAME unit1 COMMAND $)
>
> Note that NAME and COMMAND are required for this to work.
>
> BTW: EXECUTABLE_OUTPUT_PATH is deprecated, you should use
> CMAKE_RUNTIME_OUTPUT_DIRECTORY instead.
>
>
I changed EXE to that CMAKE RUNTIME thing, thanks.
That NAME/COMMAND thing doesn't work for me at all. Can't find the binary
without the runtime output path explicitly added.
This is what I tried:
In parent CMakeLists.txt
ENABLE_TESTING()
set (CMAKE_TEST_COMMAND ctest -V)
function (add_unit_test name)
if(NOT TARGET ${name})
add_custom_target (check COMMAND ${CMAKE_TEST_COMMAND})
endif()
add_executable(${name} ${ARGN})
add_test(NAME ${name} COMMAND $)
add_dependencies(check ${name})
endfunction()
in subdirectory CMakeLists.txt
add_unit_test(unit_string_numeric_utils units/unit_string_numeric_utils.cpp
string_numeric_utils.cpp)
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] building tests
On 8. Jul, 2010, at 7:25 , Paul Harris wrote:
> On 8 July 2010 12:56, Michael Wild wrote:
>
>>
>> On 8. Jul, 2010, at 4:40 , Paul Harris wrote:
>>
>>> On 7 July 2010 23:05, Michael Wild wrote:
>>>
On 7. Jul, 2010, at 16:01 , Paul Harris wrote:
> Hi all,
>
> I have looked and can't find the answer, so I turn to the list.
>
> I have a CMakeLists.txt and a subdirectory called utils, which also has
its
> own CMakeLists.txt
>
> In the parent CML.txt, I have something like:
>
> ENABLE_TESTING()
> add_subdirectory(utils)
>
> In my utils CML.txt, I have
>
> ADD_EXECUTABLE(unit_1 units/unit_1.cpp)
> ADD_TEST( unit_1 ${EXECUTABLE_OUTPUT_PATH}/unit_1 )
>
Simplify this to
ADD_TEST(unit_1 unit_1)
CMake will figure out by itself that unit_1 is a target and invoke the
executable correctly (your code would break for multi-configuration IDE
generators).
>>> This does not work for me. If I do not have the EXECUTABLE_OUTPUT_PATH
>> in
>>> add_test, I get a message like this when i run "make test" (shortened for
>>> brevity):
>>>
>>> 1/ 1 Testing unit_string_numeric_utils Could not find executable
>>> unit_string_numeric_utils
>>> Looked in the following places:
>>> unit_string_numeric_utils
>>> unit_string_numeric_utils
>>> Release/unit_string_numeric_utils
>>> Release/unit_string_numeric_utils
>>
>> Mmmh, works fine for me:
>>
>> ->8-
>> cmake_minimum_required(VERSION 2.8)
>> project(tmp)
>>
>> enable_testing()
>>
>> add_executable(unit1 unit1.cpp)
>> add_test(unit1 unit1)
>> -<8-
>>
>> Where unit1.cpp is just a simple hello-world program. Running it:
>>
>>
> snip
>
> My project is a lot bigger than a hello-world program. It has
> subdirectories for a start, and I do things like
> SET(EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR}/bin CACHE INTERNAL "Single
> output directory for building all executables.")
>
> I'm not sure at which point things stop working, do you want me to try and
> build a test-case?
You are right, it seems that the documentation is misleading (or IMHO outright
wrong). This, however, works for me and is safe:
add_test(NAME unit1 COMMAND $)
Note that NAME and COMMAND are required for this to work.
BTW: EXECUTABLE_OUTPUT_PATH is deprecated, you should use
CMAKE_RUNTIME_OUTPUT_DIRECTORY instead.
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] building tests
On 8 July 2010 12:56, Michael Wild wrote:
>
> On 8. Jul, 2010, at 4:40 , Paul Harris wrote:
>
> > On 7 July 2010 23:05, Michael Wild wrote:
> >
> >>
> >> On 7. Jul, 2010, at 16:01 , Paul Harris wrote:
> >>
> >>> Hi all,
> >>>
> >>> I have looked and can't find the answer, so I turn to the list.
> >>>
> >>> I have a CMakeLists.txt and a subdirectory called utils, which also has
> >> its
> >>> own CMakeLists.txt
> >>>
> >>> In the parent CML.txt, I have something like:
> >>>
> >>> ENABLE_TESTING()
> >>> add_subdirectory(utils)
> >>>
> >>> In my utils CML.txt, I have
> >>>
> >>> ADD_EXECUTABLE(unit_1 units/unit_1.cpp)
> >>> ADD_TEST( unit_1 ${EXECUTABLE_OUTPUT_PATH}/unit_1 )
> >>>
> >>
> >> Simplify this to
> >>
> >> ADD_TEST(unit_1 unit_1)
> >>
> >> CMake will figure out by itself that unit_1 is a target and invoke the
> >> executable correctly (your code would break for multi-configuration IDE
> >> generators).
> >>
> >>
> > This does not work for me. If I do not have the EXECUTABLE_OUTPUT_PATH
> in
> > add_test, I get a message like this when i run "make test" (shortened for
> > brevity):
> >
> > 1/ 1 Testing unit_string_numeric_utils Could not find executable
> > unit_string_numeric_utils
> > Looked in the following places:
> > unit_string_numeric_utils
> > unit_string_numeric_utils
> > Release/unit_string_numeric_utils
> > Release/unit_string_numeric_utils
>
> Mmmh, works fine for me:
>
> ->8-
> cmake_minimum_required(VERSION 2.8)
> project(tmp)
>
> enable_testing()
>
> add_executable(unit1 unit1.cpp)
> add_test(unit1 unit1)
> -<8-
>
> Where unit1.cpp is just a simple hello-world program. Running it:
>
>
snip
My project is a lot bigger than a hello-world program. It has
subdirectories for a start, and I do things like
SET(EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR}/bin CACHE INTERNAL "Single
output directory for building all executables.")
I'm not sure at which point things stop working, do you want me to try and
build a test-case?
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] building tests
On 8. Jul, 2010, at 4:40 , Paul Harris wrote:
> On 7 July 2010 23:05, Michael Wild wrote:
>
>>
>> On 7. Jul, 2010, at 16:01 , Paul Harris wrote:
>>
>>> Hi all,
>>>
>>> I have looked and can't find the answer, so I turn to the list.
>>>
>>> I have a CMakeLists.txt and a subdirectory called utils, which also has
>> its
>>> own CMakeLists.txt
>>>
>>> In the parent CML.txt, I have something like:
>>>
>>> ENABLE_TESTING()
>>> add_subdirectory(utils)
>>>
>>> In my utils CML.txt, I have
>>>
>>> ADD_EXECUTABLE(unit_1 units/unit_1.cpp)
>>> ADD_TEST( unit_1 ${EXECUTABLE_OUTPUT_PATH}/unit_1 )
>>>
>>
>> Simplify this to
>>
>> ADD_TEST(unit_1 unit_1)
>>
>> CMake will figure out by itself that unit_1 is a target and invoke the
>> executable correctly (your code would break for multi-configuration IDE
>> generators).
>>
>>
> This does not work for me. If I do not have the EXECUTABLE_OUTPUT_PATH in
> add_test, I get a message like this when i run "make test" (shortened for
> brevity):
>
> 1/ 1 Testing unit_string_numeric_utils Could not find executable
> unit_string_numeric_utils
> Looked in the following places:
> unit_string_numeric_utils
> unit_string_numeric_utils
> Release/unit_string_numeric_utils
> Release/unit_string_numeric_utils
Mmmh, works fine for me:
->8-
cmake_minimum_required(VERSION 2.8)
project(tmp)
enable_testing()
add_executable(unit1 unit1.cpp)
add_test(unit1 unit1)
-<8-
Where unit1.cpp is just a simple hello-world program. Running it:
->8-
$ mkdir build
$ cd build
$ cmake ..
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Checking whether C compiler has -isysroot
-- Checking whether C compiler has -isysroot - yes
-- Checking whether C compiler supports OSX deployment target flag
-- Checking whether C compiler supports OSX deployment target flag - yes
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Checking whether CXX compiler has -isysroot
-- Checking whether CXX compiler has -isysroot - yes
-- Checking whether CXX compiler supports OSX deployment target flag
-- Checking whether CXX compiler supports OSX deployment target flag - yes
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/mwild/tmp/cmake/tests/build
$ make all test
Scanning dependencies of target unit1
[100%] Building CXX object CMakeFiles/unit1.dir/unit1.cpp.o
Linking CXX executable unit1
[100%] Built target unit1
Running tests...
Test project /Users/mwild/tmp/cmake/tests/build
Start 1: unit1
1/1 Test #1: unit1 Passed0.00 sec
100% tests passed, 0 tests failed out of 1
Total Test time (real) = 0.01 sec
-<8-
Michael
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] building tests
On 7 July 2010 23:38, Marcel Loose wrote:
> On Wed, 2010-07-07 at 17:05 +0200, Michael Wild wrote:
> > On 7. Jul, 2010, at 16:01 , Paul Harris wrote:
> >
> > > Hi all,
> > >
> > > I have looked and can't find the answer, so I turn to the list.
> > >
> > > I have a CMakeLists.txt and a subdirectory called utils, which also
> has its
> > > own CMakeLists.txt
> > >
> > > In the parent CML.txt, I have something like:
> > >
> > > ENABLE_TESTING()
> > > add_subdirectory(utils)
> > >
> > > In my utils CML.txt, I have
> > >
> > > ADD_EXECUTABLE(unit_1 units/unit_1.cpp)
> > > ADD_TEST( unit_1 ${EXECUTABLE_OUTPUT_PATH}/unit_1 )
> > >
> >
> > Simplify this to
> >
> > ADD_TEST(unit_1 unit_1)
> >
> > CMake will figure out by itself that unit_1 is a target and invoke the
> executable correctly (your code would break for multi-configuration IDE
> generators).
> >
> > As for the dependencies, I agree that it would be nice if the "test"
> target depended on the executables. But what is wrong with "make all
> test" (apart from the fact that it possibly compiles more than you
> actually need to run the test)? You could also wrap the add_executable
> call in a custom function which creates a custom target (say test_exes)
> and makes it depend on all the executables:
> >
> > function(add_test_executable name)
> > if(NOT TARGET ${name})
> > add_custom_target(test_exes)
> >endif()
> >add_executable(${name} ${ARGN})
> >add_dependencies(test_exes ${name})
> > endfunction()
> >
> > Then you can do "make test_exes test".
> >
> > HTH
> >
> > Michael
>
> You can further reduce the number of targets that get (re)build by going
> into the directory '${CMAKE_BINARY_DIR}/utils' and invoke 'make' there.
>
> You could also define a 'check' target that will build and run all your
> test programs. See http://www.cmake.org/Wiki/CMakeEmulateMakeCheck
>
> Best regards,
> Marcel Loose.
>
>
Thanks Marcel, I combined the solution in the wiki with what was discussed
in my last email, and I ended up with
set (CMAKE_TEST_COMMAND "ctest")
function (add_unit_test name)
if(NOT TARGET ${name})
add_custom_target (check COMMAND ${CMAKE_TEST_COMMAND})
endif()
add_executable(${name} ${ARGN})
# or ADD_EXECUTABLE(${name} ${ARGN} EXCLUDE_FROM_ALL)
#if you want it to be skipped when building 'all'
add_test(${name} ${EXECUTABLE_OUTPUT_PATH}/${name})
add_dependencies(check ${name})
endfunction()
however, I have discovered (with message()) that ${CMAKE_TEST_COMMAND} is
*empty* - its something I had to set(), which is not mentioned in the wiki
page you mentioned. It IS kind-of-mentioned in "Cmake Scripting of CTest"
but not explicitly enough to catch the eye.
I've edited the wiki page, please check that my edits make sense.
Thanks
Paul
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] building tests
On 7 July 2010 23:05, Michael Wild wrote:
>
> On 7. Jul, 2010, at 16:01 , Paul Harris wrote:
>
> > Hi all,
> >
> > I have looked and can't find the answer, so I turn to the list.
> >
> > I have a CMakeLists.txt and a subdirectory called utils, which also has
> its
> > own CMakeLists.txt
> >
> > In the parent CML.txt, I have something like:
> >
> > ENABLE_TESTING()
> > add_subdirectory(utils)
> >
> > In my utils CML.txt, I have
> >
> > ADD_EXECUTABLE(unit_1 units/unit_1.cpp)
> > ADD_TEST( unit_1 ${EXECUTABLE_OUTPUT_PATH}/unit_1 )
> >
>
> Simplify this to
>
> ADD_TEST(unit_1 unit_1)
>
> CMake will figure out by itself that unit_1 is a target and invoke the
> executable correctly (your code would break for multi-configuration IDE
> generators).
>
>
This does not work for me. If I do not have the EXECUTABLE_OUTPUT_PATH in
add_test, I get a message like this when i run "make test" (shortened for
brevity):
1/ 1 Testing unit_string_numeric_utils Could not find executable
unit_string_numeric_utils
Looked in the following places:
unit_string_numeric_utils
unit_string_numeric_utils
Release/unit_string_numeric_utils
Release/unit_string_numeric_utils
> As for the dependencies, I agree that it would be nice if the "test" target
> depended on the executables. But what is wrong with "make all test" (apart
> from the fact that it possibly compiles more than you actually need to run
> the test)? You could also wrap
I want to only build the tests, because for today's job, rebuilding my unit
tests takes 2 seconds, which I'll do a dozen times as I add functionality.
linking the libraries that would be affected by my changes would take 60
seconds or more.
> the add_executable call in a custom function which creates a custom target
> (say test_exes) and makes it depend on all the executables:
>
> function(add_test_executable name)
> if(NOT TARGET ${name})
>add_custom_target(test_exes)
> endif()
> add_executable(${name} ${ARGN})
>
add_test(${name} ${EXECUTABLE_OUTPUT_PATH}/${name})
> add_dependencies(test_exes ${name})
> endfunction()
>
>
This works well for me, brilliant!except I added the add_test() line
(above)
> Then you can do "make test_exes test".
>
>
This does not work for me, as I run it like so:
make -j8 test_exes test (yes I have 8 CPUs)
and that runs the 'test' before / in parallel with test_exes.
I have tried to resolve that with my next email to Marcel...
Paul
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] building tests
On Wed, 2010-07-07 at 17:05 +0200, Michael Wild wrote:
> On 7. Jul, 2010, at 16:01 , Paul Harris wrote:
>
> > Hi all,
> >
> > I have looked and can't find the answer, so I turn to the list.
> >
> > I have a CMakeLists.txt and a subdirectory called utils, which also
has its
> > own CMakeLists.txt
> >
> > In the parent CML.txt, I have something like:
> >
> > ENABLE_TESTING()
> > add_subdirectory(utils)
> >
> > In my utils CML.txt, I have
> >
> > ADD_EXECUTABLE(unit_1 units/unit_1.cpp)
> > ADD_TEST( unit_1 ${EXECUTABLE_OUTPUT_PATH}/unit_1 )
> >
>
> Simplify this to
>
> ADD_TEST(unit_1 unit_1)
>
> CMake will figure out by itself that unit_1 is a target and invoke the
executable correctly (your code would break for multi-configuration IDE
generators).
>
> As for the dependencies, I agree that it would be nice if the "test"
target depended on the executables. But what is wrong with "make all
test" (apart from the fact that it possibly compiles more than you
actually need to run the test)? You could also wrap the add_executable
call in a custom function which creates a custom target (say test_exes)
and makes it depend on all the executables:
>
> function(add_test_executable name)
> if(NOT TARGET ${name})
> add_custom_target(test_exes)
>endif()
>add_executable(${name} ${ARGN})
>add_dependencies(test_exes ${name})
> endfunction()
>
> Then you can do "make test_exes test".
>
> HTH
>
> Michael
You can further reduce the number of targets that get (re)build by going
into the directory '${CMAKE_BINARY_DIR}/utils' and invoke 'make' there.
You could also define a 'check' target that will build and run all your
test programs. See http://www.cmake.org/Wiki/CMakeEmulateMakeCheck
Best regards,
Marcel Loose.
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] building tests
On 7. Jul, 2010, at 16:01 , Paul Harris wrote:
> Hi all,
>
> I have looked and can't find the answer, so I turn to the list.
>
> I have a CMakeLists.txt and a subdirectory called utils, which also has its
> own CMakeLists.txt
>
> In the parent CML.txt, I have something like:
>
> ENABLE_TESTING()
> add_subdirectory(utils)
>
> In my utils CML.txt, I have
>
> ADD_EXECUTABLE(unit_1 units/unit_1.cpp)
> ADD_TEST( unit_1 ${EXECUTABLE_OUTPUT_PATH}/unit_1 )
>
Simplify this to
ADD_TEST(unit_1 unit_1)
CMake will figure out by itself that unit_1 is a target and invoke the
executable correctly (your code would break for multi-configuration IDE
generators).
As for the dependencies, I agree that it would be nice if the "test" target
depended on the executables. But what is wrong with "make all test" (apart from
the fact that it possibly compiles more than you actually need to run the
test)? You could also wrap the add_executable call in a custom function which
creates a custom target (say test_exes) and makes it depend on all the
executables:
function(add_test_executable name)
if(NOT TARGET ${name})
add_custom_target(test_exes)
endif()
add_executable(${name} ${ARGN})
add_dependencies(test_exes ${name})
endfunction()
Then you can do "make test_exes test".
HTH
Michael
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building tests only for "make test"
Hi Stefan, You found a typo. I'll fix that right away. Thanks. I've never tried to use the 'check' target with ctest, so I'm not sure whether it should work or not. Maybe someone else can comment on this. Best regards, Marcel Loose. On Mon, 2009-12-14 at 12:49 +0100, Dr. Stefan Sablatnög wrote: > Hi Marcel, > > Thanks for the hint, the wiki states it should be CMAKE_TEST_COMMAND, > I think this should be CMAKE_CTEST_COMMMAND? > > By the way is there a way to make ctest use this new check target instead of > the default all in a continous testing configuration? > (I tried ctest.exe --build-target check -D ContinuousStart -D > ContinuousUpdate -D ContinuousConfigure -D ContinuousBuild -D ContinuousTest > -D ContinuousSubmit > And it didn't work as expected, but maybe I made a mistake) > > Thanks > Stefan > > > -Original Message- > From: Marcel Loose [mailto:lo...@astron.nl] > Sent: Freitag, 11. Dezember 2009 18:17 > To: stefan.sablatn...@svox.com > Cc: cmake@cmake.org > Subject: Re: [CMake] Building tests only for "make test" > > Hi Stefan, > > I once dug into this issue, because I wanted to (more or less) emulate > the GNU Autotools 'make check' feature. Have a look at > http://www.cmake.org/Wiki/CMakeEmulateMakeCheck and see if that answers > you question. > > Best regards, > Marcel Loose. > > On Fri, 2009-12-11 at 15:53 +0100, Dr. Stefan Sablatnög wrote: > > Hi all, > > > > > > > > I face a (probably simple) problem: > > > > > > > > I want to build a project, that includes tests, but these should not > > be build on > > > > default, so I added EXCLUDE_FROM_ALL to the add_executable command. > > > > > > > > How can I force them to be built when testing ? > > > > (we test through make test and continuously via a ctest script) > > > > > > > > Is there a simple solution? > > > > > > > > Thanks in advance > > > > Stefan > > > > -- > > > > > > > > best regards > > > > > > > > Dr. Stefan Sablatnög > > > > > > > > email: stefan.sablatn...@svox.com > > > > phone: ++49 731 15239474 > > > > address: > > > > SVOX Ulm > > > > Magirus Deutz-Straße 16 > > > > 89077 Ulm > > > > > > > > > > > > > > ___ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > > > Follow this link to subscribe/unsubscribe: > > http://www.cmake.org/mailman/listinfo/cmake > > ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building tests only for "make test"
Hi Marcel, Thanks for the hint, the wiki states it should be CMAKE_TEST_COMMAND, I think this should be CMAKE_CTEST_COMMMAND? By the way is there a way to make ctest use this new check target instead of the default all in a continous testing configuration? (I tried ctest.exe --build-target check -D ContinuousStart -D ContinuousUpdate -D ContinuousConfigure -D ContinuousBuild -D ContinuousTest -D ContinuousSubmit And it didn't work as expected, but maybe I made a mistake) Thanks Stefan -Original Message- From: Marcel Loose [mailto:lo...@astron.nl] Sent: Freitag, 11. Dezember 2009 18:17 To: stefan.sablatn...@svox.com Cc: cmake@cmake.org Subject: Re: [CMake] Building tests only for "make test" Hi Stefan, I once dug into this issue, because I wanted to (more or less) emulate the GNU Autotools 'make check' feature. Have a look at http://www.cmake.org/Wiki/CMakeEmulateMakeCheck and see if that answers you question. Best regards, Marcel Loose. On Fri, 2009-12-11 at 15:53 +0100, Dr. Stefan Sablatnög wrote: > Hi all, > > > > I face a (probably simple) problem: > > > > I want to build a project, that includes tests, but these should not > be build on > > default, so I added EXCLUDE_FROM_ALL to the add_executable command. > > > > How can I force them to be built when testing ? > > (we test through make test and continuously via a ctest script) > > > > Is there a simple solution? > > > > Thanks in advance > > Stefan > > -- > > > > best regards > > > > Dr. Stefan Sablatnög > > > > email: stefan.sablatn...@svox.com > > phone: ++49 731 15239474 > > address: > > SVOX Ulm > > Magirus Deutz-Straße 16 > > 89077 Ulm > > > > > > > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building tests only for "make test"
Hi Stefan, I once dug into this issue, because I wanted to (more or less) emulate the GNU Autotools 'make check' feature. Have a look at http://www.cmake.org/Wiki/CMakeEmulateMakeCheck and see if that answers you question. Best regards, Marcel Loose. On Fri, 2009-12-11 at 15:53 +0100, Dr. Stefan Sablatnög wrote: > Hi all, > > > > I face a (probably simple) problem: > > > > I want to build a project, that includes tests, but these should not > be build on > > default, so I added EXCLUDE_FROM_ALL to the add_executable command. > > > > How can I force them to be built when testing ? > > (we test through make test and continuously via a ctest script) > > > > Is there a simple solution? > > > > Thanks in advance > > Stefan > > -- > > > > best regards > > > > Dr. Stefan Sablatnög > > > > email: stefan.sablatn...@svox.com > > phone: ++49 731 15239474 > > address: > > SVOX Ulm > > Magirus Deutz-Straße 16 > > 89077 Ulm > > > > > > > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
