MantisBT - CMake
View Issue Details
0008774CMakeCMakepublic2009-03-20 16:232016-06-10 14:30
Bill Hoffman 
0008774: RUN_TESTS project & dependencies
A thread that fully describes this feature request can be found on the CMake mailing list. The thread's URL is below: [^]
No tags attached.
Issue History
2009-03-20 16:23MrDoomMasterNew Issue
2009-03-22 21:56Bill HoffmanStatusnew => assigned
2009-03-22 21:56Bill HoffmanAssigned To => Bill Hoffman
2009-04-07 20:33Paul Oppenheim (Poppy Linden)Note Added: 0015959
2009-04-08 04:46MrDoomMasterNote Added: 0015961
2009-04-08 15:27Paul Oppenheim (Poppy Linden)Note Added: 0015973
2009-04-23 05:51Hugo HedenNote Added: 0016150
2009-04-23 05:52Hugo HedenNote Edited: 0016150
2009-04-23 05:53Hugo HedenNote Edited: 0016150
2014-09-06 15:34Jean-Bernard JansenNote Added: 0036737
2015-01-21 21:14cxjNote Added: 0037765
2015-08-09 11:34David ZemonNote Added: 0039255
2015-12-15 15:14Taylor Braun-JonesNote Added: 0039987
2016-04-25 15:29Louis DionneNote Added: 0040929
2016-06-10 14:27Kitware RobotNote Added: 0041521
2016-06-10 14:27Kitware RobotStatusassigned => resolved
2016-06-10 14:27Kitware RobotResolutionopen => moved
2016-06-10 14:30Kitware RobotStatusresolved => closed

Paul Oppenheim (Poppy Linden)   
2009-04-07 20:33   
Similarly, when adding tests I wrote an ADD_DEPENDENCIES line, assuming they behaved like targets. I think having a correct dependency chain for tests would have the same effect, and would catch targets that are not in BUILD_ALL.
2009-04-08 04:46   
But tests *are* targets just like everything else. I don't see what you mean. If you have a static library project that a test depends on, then you would call add_dependencies on that project. However, tests do not require a dependency like that.
Paul Oppenheim (Poppy Linden)   
2009-04-08 15:27   
MrDoomMaster, that is false. You cannot use add_dependencies on a test target. You will get "add_dependencies Adding dependency to non-existent target:" (defined in cmAddDependenciesCommand.cxx). I suggest you try it.

Changing that behavior would enable correct dependencies to be made, and then RUN_TESTS would be able to generate the correct dependencies. This would only work when running the RUN_TESTS target, unless CTest were also given the ability to go back into the build to compile the targets it needs. I think that would be outside the scope of this issue.
Hugo Heden   
2009-04-23 05:51   
(edited on: 2009-04-23 05:53)
poppy: What you are looking for in comment 1 and comment 3 would perhaps be bug 0008438?

Jean-Bernard Jansen   
2014-09-06 15:34   
@Hugon Heden : I dont think so. In my opinion, the add_test directive should automatically add the dependency. A test cannot be expected to work without first building the corresponding exe. So the add_test directive coul be able to decide if the given exe is a target and add the dependecy if it is the case.

That is the behavior I expected from CTest in the first place.
2015-01-21 21:14   
It seems to me that "make test" should work exactly like "make install" as far as when it rebuilds dependencies.
David Zemon   
2015-08-09 11:34   
Where's the "up vote" button? I'm trying to start using CTest today and just discovered this. Very disappointing :(
Taylor Braun-Jones   
2015-12-15 15:14   
Is there something that makes this a fundamentally challenging bug to solve? If not, could one of the CMake devs give some guidance on how they'd like to see the solution implemented? I'd be willing to submit a patch for this.
Louis Dionne   
2016-04-25 15:29   
This feature request is about 7 years old. It would be great if it was either implemented or dropped for good, with a proper rationale. The requested behavior is what's expected by most new users of CTest (see [1]), and the current behavior is very annoying.

I'm coming here because of a discussion [2] on the Boost mailing list, where they're saying that CMake can't build and run a subset of a test suite. That would be possible if CTest automatically built the executable required for a unit test; we could just use `ctest -R some_regex` and everything would work. This is just one example of useless confusion caused by the current behavior, but there are probably many other similar cases.

Can this be fixed, pretty please?

[1]: [^]
[2]: [^]
Kitware Robot   
2016-06-10 14:27   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.