View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003796CMakeCMakepublic2006-09-23 14:122010-11-09 22:57
ReporterJacob Foshee 
Assigned ToDavid Cole 
PlatformOSOS Version
Product Version 
Target VersionCMake 2.8.3Fixed in VersionCMake 2.8.3 
Summary0003796: Add Project Group command
DescriptionVisual 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.
TagsNo tags attached.
Attached Filespatch file icon cmake_vs_project_folder.patch [^] (5,854 bytes) 2009-05-05 09:28 [Show Content]
patch file icon auto_project_groups.patch [^] (5,377 bytes) 2009-12-18 21:50 [Show Content]
zip file icon [^] (13,161 bytes) 2010-03-01 11:38
? file icon cmake.exe [^] (2,613,248 bytes) 2010-08-26 08:54
zip file icon [^] (12,985 bytes) 2010-08-26 10:15
? file icon cmake-2.8.2.exe [^] (2,772,992 bytes) 2010-08-27 10:27

- Relationships Relation Graph ] Dependency Graph ]
related to 0008738closedBill Hoffman Add NEST_SOLUTION_FOLDERS for Visual Studio Generator 
related to 0011436closedDavid Cole Solution folder property does not work with include_external_msproject in cmake 2.8.3 

-  Notes
Bill Hoffman (manager)
2006-10-03 13:27

How do you use this feature? What version of VS?
Jacob Foshee (reporter)
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.
Bill Hoffman (manager)
2006-10-04 09:59

I think this is a VS8 feature. I guess we could ignore it for other versions of VS.
Bill Hoffman (manager)
2008-10-07 16:33

OK, so how about something like this:


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}"
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "MyFolder2", "MyFolder2", "{26DBDF98-8DEE-459F-8896-DBD09E8F9E8F}"

    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}

890DB4DF-64B5-4942-84E9-DF67723BB1EA = foo
A58087FC-1CF6-459B-80DD-78CC5D405155 = bar
F672E97A-1991-4839-B3DA-2DB7EC139531 = stuff
Guillaume Chevallereau (reporter)
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).
Guillaume Chevallereau (reporter)
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.

Christophe Riccio (reporter)
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.
Josh Quigley (reporter)
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.
Johannes Brunen (reporter)
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.
Joe Drago (reporter)
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:


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.
Joe Drago (reporter)
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:


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


Anyway, I figured I'd flag my potentially dubious feature myself. :-)
Joe Drago (reporter)
2010-01-06 13:19

Wow, after reworking some of that, it turns out VS Express doesn't "support" SolutionDirs. How obnoxious.
James Bigler (developer)
2010-02-11 12:59

This looks like a sweet feature that would be greatly appreciated by my group.
Surya Kiran (reporter)
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.

tomschi (reporter)
2010-03-01 11:43

today i combined the recent sources (2.8.0) with the changes from gchevallereau and [^] 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.
Ryan Pavlik (reporter)
2010-03-24 08:03

It would be useful to make this solution general enough to work with XCode as well.
d3x0r (reporter)
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.
tetractius (reporter)
2010-05-26 12:04

... and I think that this should be an important feature that to be officially implemented...
David Cole (manager)
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?
DD (reporter)
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.
DD (reporter)
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 :)
Mike Wittman (reporter)
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.
Rolf Eike Beer (developer)
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.
David Cole (manager)
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?
David Cole (manager)
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...
Philip Lowman (developer)
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.
John M. Drescher (reporter)
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.
Jean-eudes (reporter)
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:

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.

tomschi (reporter)
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.
tomschi (reporter)
2010-08-26 10:20 now contains the patched source files from the 2.8.2 source package.
This patch also works for MSVC 2010 now.
Jean-eudes (reporter)
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!
David Cole (manager)
2010-09-03 14:33

This commit is now in 'next' :;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
       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
       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
       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.
David Cole (manager)
2010-10-06 13:43

One more commit:;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.

- Issue History
Date Modified Username Field Change
2008-10-07 16:33 Bill Hoffman Note Added: 0013759
2009-05-05 09:27 Guillaume Chevallereau Note Added: 0016285
2009-05-05 09:28 Guillaume Chevallereau File Added: cmake_vs_project_folder.patch
2009-05-05 09:37 Guillaume Chevallereau Note Added: 0016286
2009-05-05 09:46 Guillaume Chevallereau Note Edited: 0016286
2009-05-05 10:28 Christophe Riccio Note Added: 0016287
2009-09-17 08:33 Josh Quigley Note Added: 0017583
2009-11-17 10:11 Johannes Brunen Note Added: 0018465
2009-12-18 21:50 Joe Drago File Added: auto_project_groups.patch
2009-12-18 21:57 Joe Drago Note Added: 0018951
2009-12-18 22:01 Joe Drago Note Added: 0018952
2010-01-06 13:19 Joe Drago Note Added: 0019044
2010-02-11 12:59 James Bigler Note Added: 0019510
2010-03-01 08:31 Surya Kiran Note Added: 0019663
2010-03-01 08:43 Surya Kiran Note Edited: 0019663
2010-03-01 11:38 tomschi File Added:
2010-03-01 11:43 tomschi Note Added: 0019665
2010-03-24 08:03 Ryan Pavlik Note Added: 0020002
2010-03-25 02:52 d3x0r Note Added: 0020004
2010-05-26 12:04 tetractius Note Added: 0020822
2010-08-17 23:36 David Cole Note Added: 0021786
2010-08-20 12:03 DD Note Added: 0021866
2010-08-20 12:09 DD Note Added: 0021867
2010-08-20 12:48 Mike Wittman Note Added: 0021868
2010-08-24 02:02 Rolf Eike Beer Note Added: 0021911
2010-08-24 06:59 David Cole Note Added: 0021913
2010-08-24 07:03 David Cole Note Added: 0021914
2010-08-24 21:29 Philip Lowman Note Added: 0021936
2010-08-24 22:17 John M. Drescher Note Added: 0021937
2010-08-26 08:36 Jean-eudes Note Added: 0021969
2010-08-26 08:38 Jean-eudes Note Edited: 0021969
2010-08-26 08:54 tomschi File Added: cmake.exe
2010-08-26 08:56 tomschi Note Added: 0021970
2010-08-26 10:15 tomschi File Added:
2010-08-26 10:20 tomschi Note Added: 0021971
2010-08-27 10:27 Jean-eudes File Added: cmake-2.8.2.exe
2010-08-27 10:32 Jean-eudes Note Added: 0021991
2010-08-31 17:11 David Cole Assigned To Bill Hoffman => David Cole
2010-08-31 17:55 David Cole Target Version => CMake 2.8.3
2010-09-03 14:33 David Cole Note Added: 0022084
2010-09-03 14:33 David Cole Status assigned => resolved
2010-09-03 14:33 David Cole Resolution open => fixed
2010-10-06 13:43 David Cole Note Added: 0022420
2010-10-06 13:43 David Cole Fixed in Version => CMake 2.8.3
2010-11-04 16:51 David Cole Relationship added related to 0008738
2010-11-09 22:57 Philip Lowman Status resolved => closed
2010-11-10 09:02 David Cole Relationship added related to 0011436

Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker