|
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.
|
|
cmake_vs_project_folder.patch (5,854) 2009-05-05 09:28
cmake-2.8.0-msvc-patch.zip (13,161) 2010-03-01 11:38
cmake.exe (2,613,248) 2010-08-26 08:54