MantisBT - CMake
View Issue Details
0003796CMakeCMakepublic2006-09-23 14:122010-11-09 22:57
Jacob Foshee 
David Cole 
lowfeaturealways
closedfixed 
 
CMake 2.8.3CMake 2.8.3 
0003796: Add Project Group command
Visual Studio has "Solution Folders" for grouping Projects (i.e. build targets). Large software projects would benefit from this feature. I suppose the appropriate command would be PROJECT_GROUP, to parallel SOURCE_GROUP.
No tags attached.
related to 0008738closed Bill Hoffman Add NEST_SOLUTION_FOLDERS for Visual Studio Generator 
related to 0011436closed David Cole Solution folder property does not work with include_external_msproject in cmake 2.8.3 
patch cmake_vs_project_folder.patch (5,854) 2009-05-05 09:28
https://public.kitware.com/Bug/file/2205/cmake_vs_project_folder.patch
patch auto_project_groups.patch (5,377) 2009-12-18 21:50
https://public.kitware.com/Bug/file/2733/auto_project_groups.patch
zip cmake-2.8.0-msvc-patch.zip (13,161) 2010-03-01 11:38
https://public.kitware.com/Bug/file/2920/cmake-2.8.0-msvc-patch.zip
? cmake.exe (2,613,248) 2010-08-26 08:54
https://public.kitware.com/Bug/file/3342/cmake.exe
zip cmake-2.8.2-msvc-patch.zip (12,985) 2010-08-26 10:15
https://public.kitware.com/Bug/file/3343/cmake-2.8.2-msvc-patch.zip
? cmake-2.8.2.exe (2,772,992) 2010-08-27 10:27
https://public.kitware.com/Bug/file/3346/cmake-2.8.2.exe
Issue History
2008-10-07 16:33Bill HoffmanNote Added: 0013759
2009-05-05 09:27Guillaume ChevallereauNote Added: 0016285
2009-05-05 09:28Guillaume ChevallereauFile Added: cmake_vs_project_folder.patch
2009-05-05 09:37Guillaume ChevallereauNote Added: 0016286
2009-05-05 09:46Guillaume ChevallereauNote Edited: 0016286
2009-05-05 10:28Christophe RiccioNote Added: 0016287
2009-09-17 08:33Josh QuigleyNote Added: 0017583
2009-11-17 10:11Johannes BrunenNote Added: 0018465
2009-12-18 21:50Joe DragoFile Added: auto_project_groups.patch
2009-12-18 21:57Joe DragoNote Added: 0018951
2009-12-18 22:01Joe DragoNote Added: 0018952
2010-01-06 13:19Joe DragoNote Added: 0019044
2010-02-11 12:59James BiglerNote Added: 0019510
2010-03-01 08:31Surya KiranNote Added: 0019663
2010-03-01 08:43Surya KiranNote Edited: 0019663
2010-03-01 11:38tomschiFile Added: cmake-2.8.0-msvc-patch.zip
2010-03-01 11:43tomschiNote Added: 0019665
2010-03-24 08:03Ryan PavlikNote Added: 0020002
2010-03-25 02:52d3x0rNote Added: 0020004
2010-05-26 12:04tetractiusNote Added: 0020822
2010-08-17 23:36David ColeNote Added: 0021786
2010-08-20 12:03DDNote Added: 0021866
2010-08-20 12:09DDNote Added: 0021867
2010-08-20 12:48Mike WittmanNote Added: 0021868
2010-08-24 02:02Rolf Eike BeerNote Added: 0021911
2010-08-24 06:59David ColeNote Added: 0021913
2010-08-24 07:03David ColeNote Added: 0021914
2010-08-24 21:29Philip LowmanNote Added: 0021936
2010-08-24 22:17John M. DrescherNote Added: 0021937
2010-08-26 08:36Jean-eudesNote Added: 0021969
2010-08-26 08:38Jean-eudesNote Edited: 0021969
2010-08-26 08:54tomschiFile Added: cmake.exe
2010-08-26 08:56tomschiNote Added: 0021970
2010-08-26 10:15tomschiFile Added: cmake-2.8.2-msvc-patch.zip
2010-08-26 10:20tomschiNote Added: 0021971
2010-08-27 10:27Jean-eudesFile Added: cmake-2.8.2.exe
2010-08-27 10:32Jean-eudesNote Added: 0021991
2010-08-31 17:11David ColeAssigned ToBill Hoffman => David Cole
2010-08-31 17:55David ColeTarget Version => CMake 2.8.3
2010-09-03 14:33David ColeNote Added: 0022084
2010-09-03 14:33David ColeStatusassigned => resolved
2010-09-03 14:33David ColeResolutionopen => fixed
2010-10-06 13:43David ColeNote Added: 0022420
2010-10-06 13:43David ColeFixed in Version => CMake 2.8.3
2010-11-04 16:51David ColeRelationship addedrelated to 0008738
2010-11-09 22:57Philip LowmanStatusresolved => closed
2010-11-10 09:02David ColeRelationship addedrelated to 0011436

Notes
(0005100)
Bill Hoffman   
2006-10-03 13:27   
How do you use this feature? What version of VS?
(0005122)
Jacob Foshee   
2006-10-03 16:28   
I use it in VS 8. I do not recall if it was in previous versions.

To use this feature in VS8, right click on the solution and choose Add Folder. Then click & drag projects into the folder.

This feature would be useful for solutions with a lot of projects. For example, solutions that generate a lot of DLL's, and/or have a lot of Example executables. I would like to use this feature to group DLL's, Examples, Plugins, and Applications in the CMake build of OpenSceneGraph.
(0005125)
Bill Hoffman   
2006-10-04 09:59   
I think this is a VS8 feature. I guess we could ignore it for other versions of VS.
(0013759)
Bill Hoffman   
2008-10-07 16:33   
OK, so how about something like this:

project(foo)

add_library(foo foo.c)
add_library(bar bar.c)
add_executable(stuff stuff.c)


set_target_properties(foo PROPERTIES VS_FOLDER "MyFolder")
set_target_properties(bar PROPERTIES VS_FOLDER "MyFolder")
set_target_properties(stuff PROPERTIES VS_FOLDER "MyFolder2")


This would create foo.sln with stuff like this in it:

...
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "MyFolder", "MyFolder", "{16DBDF98-8DEE-459F-8896-DBD09E8F9E8F}"
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "MyFolder2", "MyFolder2", "{26DBDF98-8DEE-459F-8896-DBD09E8F9E8F}"
EndProject

    GlobalSection(NestedProjects) = preSolution
        {890DB4DF-64B5-4942-84E9-DF67723BB1EA} = {16DBDF98-8DEE-459F-8896-DBD09E8F9E8F}
        {A58087FC-1CF6-459B-80DD-78CC5D405155} = {16DBDF98-8DEE-459F-8896-DBD09E8F9E8F}
        {F672E97A-1991-4839-B3DA-2DB7EC139531} = {26DBDF98-8DEE-459F-8896-DBD09E8F9E8F}
    EndGlobalSection

890DB4DF-64B5-4942-84E9-DF67723BB1EA = foo
A58087FC-1CF6-459B-80DD-78CC5D405155 = bar
F672E97A-1991-4839-B3DA-2DB7EC139531 = stuff
(0016285)
Guillaume Chevallereau   
2009-05-05 09:27   
I'm using the following patch to add project folder to visual studio solution.
I have tested it with Visual Studio 2005, but it should work for other version(2003 and 2008).
(0016286)
Guillaume Chevallereau   
2009-05-05 09:37   
(edited on: 2009-05-05 09:46)
Just forgot to say, i have change the property name to SOLUTION_FOLDER instead of VS_FOLDER.

(0016287)
Christophe Riccio   
2009-05-05 10:28   
I'm so glade to see this patch coming out, this is such a feature I was waiting to appear. I currently have 80 different projects in my solution... Unfortunately, I have been able to make it works. I have no error message from CMake but no folder create.
(0017583)
Josh Quigley   
2009-09-17 08:33   
What's the status of this? Is the patch compatible with latest CMake and will this patch make it in the next release?

I'm keen to use in a production environment but need to know it will be supported.

Happy to do any testing I can, VS2005/VS2008.
(0018465)
Johannes Brunen   
2009-11-17 10:11   
I'm also interested in this feature since I'm facing the same problem with solutions containing many projects. Actually, I would prefer the possibility to build a tree structure for a solution with the project as leaf nodes.
(0018951)
Joe Drago   
2009-12-18 21:57   
I took the attached patch, reorganized it a little bit in the 2.8.0 source tree, and then attached the featureset to some named properties. I've attached an alternate patch with the code (auto_project_groups.patch).

Things I changed:

* I moved all of the functionality down into cmGlobalVisualStudio8Generator, as I was under the impression that VS7 could not do Solution Dirs, so I thought it broke a layer of abstraction to put it in the base class. It can be trivially moved back up if I am wrong.

* Instead of creating new virtual functions in the base class, I just overrode two pre-existing calls and added the additional output in them.

* By default, the patch does nothing new. It doesn't even write out the empty GlobalSection(NestedProjects) block. You can enable it in your CMakeLists.txt files in one of two ways. To do it at a single project level, it'd look like:

add_library(somelib ${SOMELIB_SRCS})
set_target_properties(somelib PROPERTIES PROJECT_GROUP virtual/path/in/the/sln)

Or, as I am completely lazy, I made a global, automatic property:

set_property(GLOBAL PROPERTY AUTO_PROJECT_GROUPS 1)

If you set that in your toplevel CMakeLists.txt, it'll calculate what relative path your child CMakeLists files are in and use that as the solution folder path. I figure people can give this new patch a shot (as it uses the latest 2.8.0 snapshot) and see if they like it.
(0018952)
Joe Drago   
2009-12-18 22:01   
As a second note, my patch has a pop_back in it that is conditional on the "automatic" mode. I am not sure I like it yet, so I figured I'd mention it. An example of what that provides:

If my source tree has this path in it:

/external/languages/lua-5.1.4/CMakeLists.txt

And that file defines the "lua" library, I want my virtual solution path to be:

external/languages/lua
(versus)
external/languages/lua-5.1.4/lua

Anyway, I figured I'd flag my potentially dubious feature myself. :-)
(0019044)
Joe Drago   
2010-01-06 13:19   
Wow, after reworking some of that, it turns out VS Express doesn't "support" SolutionDirs. How obnoxious.
(0019510)
James Bigler   
2010-02-11 12:59   
This looks like a sweet feature that would be greatly appreciated by my group.
(0019663)
Surya Kiran   
2010-03-01 08:31   
(edited on: 2010-03-01 08:43)
This feature would be of great help.

With reference to 0013759, does the VS_FOLDER thing work with CMake-2.8.1 ?

I've tried set_target_properties(foo PROPERTIES VS_FOLDER "MyFolder"), but did not get it work.

(0019665)
tomschi   
2010-03-01 11:43   
today i combined the recent sources (2.8.0) with the changes from gchevallereau and http://www.cmake.org/pipermail/cmake/2007-June/014780.html. [^] i uploaded the modified source files which can be simply copied into the Source directory.
this puts CMake projects into an separate CMake solution folder and provides a SOLUTION_FOLDER property as described above.
i have used it with VS 2005 and 2008. hope it's useful and will be part of future versions.
(0020002)
Ryan Pavlik   
2010-03-24 08:03   
It would be useful to make this solution general enough to work with XCode as well.
(0020004)
d3x0r   
2010-03-25 02:52   
I would vote that when this gets implemented it be more like PROJECT_GROUP to match SOURCE_GROUP. The last patch didn't seem to work for vs2010.
(0020822)
tetractius   
2010-05-26 12:04   
... and I think that this should be an important feature that to be officially implemented...
(0021786)
David Cole   
2010-08-17 23:36   
I do not think we should accept or apply this patch unless:
- it is re-worked to include similar functionality for the Xcode generator on the Mac
- there is a test added that uses the functionality; ideally, one that independently verifies correct .sln/.vcproj or .xcodeproj structure of the generated project files

I know there are several watchers on this bug... so please chime in, whether you agree or disagree.

Are many of you actively using a cmake built with this patch applied?

Is this still important even though VS Express Editions do not support the feature?
(0021866)
DD   
2010-08-20 12:03   
David, I don't see why XCode support is required from the get go. As long as the way to group projects in the CMakeLists.txt is defined, whether or not a particular generator uses that info is moot, no?

My previous organization is migrating to CMake, and one of the gripe from Windows devs is the numerous projects is generates (partly because people designing the CMake builds have a Unix background with little regard for how it will look in an IDE like VS). They have 1 core solution with 40 projects, and 50+ plugin solutions with 10/12 projects each. Using Solution Folder made the 40 projects solution much easier to use (and build too, the build commands apply to all projects within the group for example).

My new organization has one massive single solution with 126 or 176 projects (and I don't even build all its parts), where Solution Folders would be *very* appreciated, stuffing all the tiny GTest projects into a "Unit Tests" Solution Folder.

In summary, a bit +1 to adding Solution Folder support to CMake, and the sooner the better, i.e. support in VS only is not a deal breaker IMHO, as XCode support can be added at a later date I suppose.
(0021867)
DD   
2010-08-20 12:09   
BTW, many organizations, including mine, wouldn't allow using a patched CMake, so it's not the number of people using the patch now that matter, but the number of people that would use it if it made it into the official release. Between my previous and current organizations, that would be close to 100 devs already, and many others are interested given this thread, which given that Solution Folders are not that well known, speaks to the definite demand for this. My $0.02 :)
(0021868)
Mike Wittman   
2010-08-20 12:48   
What DD said. IMO the lack of solution folders is a significant scalability problem relative to the number of libraries and executables produced by a CMake project.

I'm working with a solution that has 126 projects, consisting of about 50 core projects, 40 plugin projects, 15 example code projects, and 10 test projects, and I'm also hearing complaints from developers about the lack of organization of projects in the solution. Being able to split these types of projects into separate folders would make the CMake-generated solution *much* easier to work with.

The fact that the VS Express editions do not support solution folders should not hold back the implementation. This feature provides the greatest value when used for large-scale development, which is not the intended target of the Express editions anyway.
(0021911)
Rolf Eike Beer   
2010-08-24 02:02   
I don't see any point in blocking this until XCode is supported either. Yes, XCode support should be added. But IMHO this should not stop this feature going in for MSVC.

There also should be support for Makefiles one day so I can build group/target1, group/target2 or just group to get them both. And of course there should be group/fast.
(0021913)
David Cole   
2010-08-24 06:59   
OK. Xcode support can come later. I retract my "Xcode based objection" to this patch...

What about this, though? (my other objection)

- there is a test added that uses the functionality; ideally, one that
independently verifies correct .sln/.vcproj or .xcodeproj structure of the
generated project files

Does anybody care passionately enough about this to produce a test that verifies the correct solution file structure is generated and works with all the supported versions of Visual Studio?
(0021914)
David Cole   
2010-08-24 07:03   
DD, "the number of people using the patch now" matter to me because there is no test included with this patch.

If a significant number of people were using it now, then it would make that fact less relevant, because heavy use is itself a form of testing.

What I don't want is to put this patch in, and *then* have it end up being something that most people are not happy with because it's different than they thought it was -- so if people are actually using it as is, then that's an indicator to me that they'll be happy with the actual implementation of this patch, and not just happy with the idea of this patch from having read about it in mantis...
(0021936)
Philip Lowman   
2010-08-24 21:29   
What about moving the patch into next and throwing a win32 build of it for people on the mailing list that use Visual Studio regularly to play with? Anyone on the mailing list already running CMake 2.8 that uses Visual Studio might be interested in the feature and can try it out (with no guarantee that it will be accepted as is into master). It would get more testing this way and feedback.

I don't use Visual Studio Pro anymore so personally I don't care a great deal about this issue. I survived long enough without the feature, although it would have been really nice a couple of years ago with a project at work.
(0021937)
John M. Drescher   
2010-08-24 22:17   
I would be happy to test that. I use Visual Studio 2005 and 2008 Pro daily at work with CMake.
(0021969)
Jean-eudes   
2010-08-26 08:36   
(edited on: 2010-08-26 08:38)
I maintain a very large project with many libs, modules and programs. At this time I separately maintain VS2005/2008 solutions on windows & winCE and Eclipse ones for linux, OSX & embeded linux. I am of course very interested in using CMake to factor maintenance.

At this time I use two levels of groups before I insert my projects in VS, eg:
ComponentsGroup
  Comp1Group
    proj1
    proj2
  Comp2Group
    proj3
CoreGroup
  etc.

This kind of representation is mandatory for us and I cannot use CMake if not able to generate this tree of folders (it would be a regression for my developers, my guys are very used to it); data mining and legibility is very accelerated through this grouping mechanism.

Thus, I am very interested in testing this extension, this is a very nice feature.

Q1: Is the current patch providing multi levels of groups before projects (let say writing "ComponentGroup/Comp1Group" in the PROJECT_GROUP property)?.

Q2: Would it be possible to obtain a win32 binary that integrates the patch or do I have to necessarly rebuild?

Thx a lot.

(0021970)
tomschi   
2010-08-26 08:56   
The current patch provides multiple levels of groups before projects and i used it with MSVC 2005 and 2008.
I posted a win32-binary based on the patched 2.8.0 sources.
(0021971)
tomschi   
2010-08-26 10:20   
cmake-2.8.2-msvc-patch.zip now contains the patched source files from the 2.8.2 source package.
This patch also works for MSVC 2010 now.
(0021991)
Jean-eudes   
2010-08-27 10:32   
Thanks a lot for this answers.

Unfortunately your binary that was build on a 2.8.0 basis was not working properly when just copied in the bin folder of my 2.8.2 win32 distrib.

Thus I took your source patch (0021971 post) and rebuild using 2.8.2 source. I posted the binary in attachement. Just rename it cmake.exe and put this in the bin directory of the 2.8.2 windows distrib.

To conclude this works perfectly with version 2008 and 2005 for my testings.
I hope this will be shiped built-in next cmake release distribution.

Thanks a lot for this very usefull contrib!
(0022084)
David Cole   
2010-09-03 14:33   
This commit is now in 'next' :
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e6ac0aacf6c3ce17141870e252fda77d994782d3 [^]

Expect it will be merged to 'master' next week unless somebody raises a violent objection... :-)

You should set the FOLDER target property to the name of a folder, for example:

  set_property(TARGET cmzlib PROPERTY FOLDER "Utilities/3rdParty")

to put that target in that folder... Use "/" characters to delineate nested folders.

Related global properties also added: USE_FOLDERS and PREDEFINED_TARGETS_FOLDER. Set USE_FOLDERS to OFF to suppress this new, on-by-default feature. Set PREDEFINED_TARGETS_FOLDER if you don't like the name I chose: "CMakePredefinedTargets"

Documentation added, too:

C:\...\>bin\Debug\cmake --help-property FOLDER
cmake version 2.8.2.20100902-gXXXXXX
  FOLDER
       Set the folder name. Use to organize targets in an IDE.

       Targets with no FOLDER property will appear as top level entities in
       IDEs like Visual Studio. Targets with the same FOLDER property value
       will appear next to each other in a folder of that name. To nest
       folders, use FOLDER values such as 'GUI/Dialogs' with '/' characters
       separating folder levels.


C:\...\>bin\Debug\cmake --help-property USE_FOLDERS
cmake version 2.8.2.20100902-gXXXXXX
  USE_FOLDERS
       Use the FOLDER target property to organize targets into folders.

       If not set, CMake treats this property as ON by default. CMake
       generators that are capable of organizing into a hierarchy of folders
       use the values of the FOLDER target property to name those folders.
       See also the documentation for the FOLDER target property.


C:\...\>bin\Debug\cmake --help-property PREDEFINED_TARGETS_FOLDER
cmake version 2.8.2.20100902-gXXXXXX
  PREDEFINED_TARGETS_FOLDER
       Name of FOLDER for targets that are added automatically by CMake.

       If not set, CMake uses "CMakePredefinedTargets" as a default value for
       this property. Targets such as INSTALL, PACKAGE and RUN_TESTS will be
       organized into this FOLDER. See also the documentation for the FOLDER
       target property.
(0022420)
David Cole   
2010-10-06 13:43   
One more commit:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fd3249e11afeb38284ee8e2012134de4d410c92b [^]

To deal with the fact that VS Express editions do not support solution folders, and there is no easy/good/reliable way to tell that the user is going to use an Express edition after generation..... we default the global property USE_FOLDERS to OFF.

People who want to use this feature in their projects will have to provide an option to switch it on or off in their CMakeLists.txt file and then set the global USE_FOLDERS property appropriately.