View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008172CMakeCMakepublic2008-11-25 11:152009-01-21 17:14
ReporterDavid Karr 
Assigned ToBrad King 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformIntelOSWindowsOS VersionXP
Product VersionCMake-2-6 
Target VersionFixed in Version 
Summary0008172: ALL_BUILD is not the default StartUp Project in Visual Studio 7.0 or later versions
DescriptionThis problem occurs when someone uses CMake to generate a Visual Studio SLN file (version 7.0 or greater) for the first time in a given directory. When the user first opens the SLN file, an apparently arbitrarily chosen project, usually not ALL_BUILD, is shown as the StartUp Project by default. In order to make ALL_BUILD be the StartUp Project the user must take additional steps within Visual Studio's own interface.

This problem is not observed in Visual Studio 6.0 DSW files produced by CMake. In these files the ALL_BUILD project is usually chosen as the StartUp project by default.
Steps To ReproduceThis problem appears to be easily reproducible when a few non-default projects are included in the SLN file generated by CMake for Visual Studio 2008 (for example). Create a new directory for an out-of-source build, generate the SLN file and projects there, and open the SLN file.

If there is already an SUO file in the directory where you open the SLN file, you may not observe the problem, because the SUO file can enforce a user's prior selection of ALL_BUILD as the StartUp Project, which the user may have done through the Visual Studio interface after opening an earlier SLN file.
Additional InformationAccording to observations of the contents of various SLN files and the projects that are set as StartUp Project when each file is opened in a directory with no SUO file, it appears that Visual Studio chooses the first project listed in the SLN file to be the StartUp Project. In most (possibly all) cases the first project is not ALL_BUILD.

Visual Studio 6.0 DSW files also appear to set the first listed project as the default StartUp Project, but the first project is typically ALL_BUILD. Inspection of the CMake generators for Visual Studio shows that the change in behavior is due to the different STL container types in which project descriptions are stored in cmGlobalVisualStudio6Generator (VS6) and cmGlobalVisualStudio7Generator (VS7). In VS6 the projects are in an std::map using project names as keys, whereas in VS7 the projects are in an std::set of pointers (which are also the keys). The specifications of both containers say that their iterators visit the elements in the sequence determined by the keys; in VS6 this means lexical order of the project names, in which ALL_BUILD is usually first, but in VS7 this presumably is determined simply by which object is stored at the lowest-numbered address in memory.

The originator of this report will submit proposed code to solve the problem.
TagsNo tags attached.
Attached Fileszip file icon ForCMakeIssue8172.zip [^] (17,567 bytes) 2008-11-25 13:43

 Relationships
related to 0008400closedBrad King Visual Studio generator doesn't do copy_if_different for .sln files. 

  Notes
(0014184)
David Karr (reporter)
2008-11-25 13:49

 The attached file ForCMakeIssue8172.zip contains two CMake source files modified so that this problem is fixed, and a text file describing the changes. (It also contains a file with extension .bak that is an artifact of the development process and should be ignored.)
(0014281)
Philip Lowman (developer)
2008-12-04 02:31

 A logical extension off this patch would be a special global CMake property to set the default project if a user does not want ALL_BUILD to be the default.

Setting the default project to an executable target, for example, allows debugging to work by pressing the Debug button without the user having to set a default project.

I'm not sure which other IDEs use a default project but this could be a generic thing as many IDEs seem to follow the example of VS and clone pretty much everything.
(0014290)
David Karr (reporter)
2008-12-04 10:35

 The suggested extension would be easy to implement. In the modified version of cmGlobalVisualStudio7Generator::WriteTargetsToSolution, the literal string "ALL_BUILD" is used in two places. This string could be replaced by the value of an environment variable (stored in a new local variable to protect against modification in one use location and not in the other--in fact the file uploaded on 11/25 really should have done that too, but doesn't).

If that's desired and if someone can authoritatively name the user option, I could easily post a proper patch with this feature.
(0014654)
Brad King (manager)
2009-01-21 17:13

 CMake 2.4 and below would order targets in both VS6 and VS7 by name. This was broken in 2.6 by the feature to include dependent targets in subproject solution files. I've committed a fix to this (see issue 0008400).

However, what has always been a problem is when a target name sorts lexicographically before ALL_BUILD, like "AAA". I've committed a change to the previous fix which treats ALL_BUILD as a special case to always come first in the ordering (for VS7 and above).

/cvsroot/CMake/CMake/Source/cmGlobalVisualStudio7Generator.cxx,v <-- Source/cmGlobalVisualStudio7Generator.cxx
new revision: 1.104; previous revision: 1.103

I don't think making this configurable is worthwhile. It is hard to define an interface to specify it because some targets might not exist in subproject solution files. Furthermore, it is trivial to interactively change the active project in the VS IDE, and it preserves the change (in the .suo file) across re-generates.
(0014655)
Brad King (manager)
2009-01-21 17:14

 I've scheduled this fix to be included in 2.6.3.

 Issue History
Date Modified Username Field Change
2008-11-25 11:15 David Karr New Issue
2008-11-25 13:43 David Karr File Added: ForCMakeIssue8172.zip
2008-11-25 13:49 David Karr Note Added: 0014184
2008-12-04 02:31 Philip Lowman Note Added: 0014281
2008-12-04 10:35 David Karr Note Added: 0014290
2008-12-15 10:40 Bill Hoffman Status new => assigned
2008-12-15 10:40 Bill Hoffman Assigned To => David Cole
2009-01-21 16:53 Brad King Relationship added related to 0008400
2009-01-21 17:07 Brad King Assigned To David Cole => Brad King
2009-01-21 17:13 Brad King Note Added: 0014654
2009-01-21 17:14 Brad King Note Added: 0014655
2009-01-21 17:14 Brad King Status assigned => closed
2009-01-21 17:14 Brad King Resolution open => fixed

Copyright © 2000 - 2018 MantisBT Team