View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0013122CMakeCMakepublic2012-04-11 12:462016-06-10 14:31
Reportervoid.pointer 
Assigned ToKitware Robot 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionmoved 
PlatformWindowsOSWindowsOS Version7 x64
Product VersionCMake 2.8.7 
Target VersionFixed in Version 
Summary0013122: Allow inclusion of targets in generated solutions for Visual Studio
DescriptionWhen generating for visual studio, the project() command results in a solution being generated. Every target created thereafter will be included in this solution. However, if project() is called from a subdirectory, then targets created in parent directories will not be included in this solution *unless* included targets have a dependency on those non-included targets.

For example, if I create a custom target that copies some files as a post-build event, but that target is created in the root directory, I should be able to specify that project() commands invoked in subdirectories include those targets in its solution, for at least the purpose of having them available in the solution for manual invocation.

One way to do this I suppose would be to add an optional parameter to the project() command:

project( my_project INCLUDE parent_target1 parent_target2 )

Or a separate command could be created:

project_dependencies( my_project parent_target1 parent_target2 )

I also recommend adding some flags that determine whether or not those included targets in the solution are built with the ALL_BUILD project or not (for example, for custom targets you may not want this, and if you do need it, it might be worth it to simply add a dependency to an existing target elsewhere).

Discussion on the CMake mailing list here:
http://www.cmake.org/pipermail/cmake/2012-April/049804.html [^]
TagsNo tags attached.
Attached Files

 Relationships

  Notes
(0029128)
David Cole (manager)
2012-04-11 13:13

 This feature seems like it will be difficult to test.

I will not accept patches for this feature unless I am convinced that the test(s) added/extended by the patches do a good job of ensuring that the feature is working as expected.
(0029129)
void.pointer (reporter)
2012-04-11 14:06

 Pardon my ignorance of the logistics of CMake and its source code, but could you explain in more detail how testing will be difficult? Perhaps you have some examples in mind?
(0029130)
David Cole (manager)
2012-04-11 14:27

 The real test is an interactive one: open the solution file in Visual Studio and verify that all the "correct" projects are included.

An automated test for this would have to parse through the generated solution files and verify that all the correct references to the project files are in there.

It won't really be that difficult, but it will be time consuming. We do not presently have tests like this, so somebody will have to write them from scratch.

I want the expectations codified in source code form by whoever submits this patch for an exemplary (complex enough) project so that somebody reading the test and the CMakeLists files in it will understand the intent of what project files should show up in what solution files.

Does that make sense, clarify things enough?

Feel free to ask further questions if you need more info.
(0030393)
David Cole (manager)
2012-08-11 21:35

 Sending old, never assigned issues to the backlog.

(The age of the bug, plus the fact that it's never been assigned to anyone means that nobody is actively working on it...)

If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it: http://www.cmake.org/mailman/listinfo/cmake [^]

It's easy to re-activate a bug here if you can find a CMake developer who has the bandwidth to take it on, and ferry a fix through to our 'next' branch for dashboard testing.
(0042022)
Kitware Robot (administrator)
2016-06-10 14:28

 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.

 Issue History
Date Modified Username Field Change
2012-04-11 12:46 void.pointer New Issue
2012-04-11 13:13 David Cole Note Added: 0029128
2012-04-11 14:06 void.pointer Note Added: 0029129
2012-04-11 14:27 David Cole Note Added: 0029130
2012-08-11 21:35 David Cole Status new => backlog
2012-08-11 21:35 David Cole Note Added: 0030393
2016-06-10 14:28 Kitware Robot Note Added: 0042022
2016-06-10 14:28 Kitware Robot Status backlog => resolved
2016-06-10 14:28 Kitware Robot Resolution open => moved
2016-06-10 14:28 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:31 Kitware Robot Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team