MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0015578CMakeCMakepublic2015-05-20 13:102016-06-10 14:21
ReporterDavy Durham 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionCMake 3.6Fixed in VersionCMake 3.6 
Summary0015578: Target property that sets Startup Project in MSVC
DescriptionA means of setting the (default) "startup project" for MS Visual Studio projects would be great.

This is a rehash of mantis2919. In needing the same functionality, the consensus "out there" is to use https://github.com/michaKFromParis/slnStartupProject [^] after generating the msvc solution with cmake.

It is true that the startup project preference is stored in the .suo file and that cmake doesn't generate that, but that's *after* the solution has been opened for the first time. .suo files are not normally stored in source control because they change so much.

MSVC apparently sets the first project defined in the .sln as the startup project when it is first opened (before any .suo file exists). And this is what this slnStartupProject application actually alters about the .sln file its given.

Would it be possible to add a command, or target property for making sure some specific target is defined first in the .sln file? This would really be helpful.

I can do more research if required.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0002919closed Bill Hoffman commnd to set the Startup Project in MSVC 
has duplicate 0015931closed Kitware Robot Change the StartUp-Solution by Value 
Attached Filespatch 0001-fixup-VS-Add-option-to-choose-the-.sln-startup-proje.patch (2,953) 2016-03-22 09:34
https://public.kitware.com/Bug/file/5650/0001-fixup-VS-Add-option-to-choose-the-.sln-startup-proje.patch
patch 0002-VS-Fix-default-target-support-for-targets-nested-ins.patch (3,145) 2016-03-22 09:34
https://public.kitware.com/Bug/file/5651/0002-VS-Fix-default-target-support-for-targets-nested-ins.patch
patch 0003-Put-ALL_BUILD-in-the-PREDEFINED_TARGETS_FOLDER.patch (1,385) 2016-03-22 09:34
https://public.kitware.com/Bug/file/5652/0003-Put-ALL_BUILD-in-the-PREDEFINED_TARGETS_FOLDER.patch
Issue History
Date ModifiedUsernameFieldChange
2015-05-20 13:10Davy DurhamNew Issue
2015-05-20 14:03Brad KingRelationship addedrelated to 0002919
2015-05-20 14:06Brad KingNote Added: 0038785
2015-05-20 15:25Davy DurhamNote Added: 0038786
2015-05-21 08:38Brad KingNote Added: 0038787
2015-05-21 11:08Davy DurhamNote Added: 0038791
2015-05-21 11:23Brad KingNote Added: 0038792
2016-03-15 16:54Nils GladitzRelationship addedhas duplicate 0015931
2016-03-16 15:47Davy DurhamNote Added: 0040705
2016-03-16 16:04Brad KingNote Added: 0040706
2016-03-18 12:41Taylor Braun-JonesNote Added: 0040729
2016-03-22 07:59Brad KingNote Added: 0040738
2016-03-22 07:59Brad KingStatusnew => resolved
2016-03-22 07:59Brad KingResolutionopen => fixed
2016-03-22 07:59Brad KingFixed in Version => CMake 3.6
2016-03-22 07:59Brad KingTarget Version => CMake 3.6
2016-03-22 09:34Taylor Braun-JonesFile Added: 0001-fixup-VS-Add-option-to-choose-the-.sln-startup-proje.patch
2016-03-22 09:34Taylor Braun-JonesFile Added: 0002-VS-Fix-default-target-support-for-targets-nested-ins.patch
2016-03-22 09:34Taylor Braun-JonesFile Added: 0003-Put-ALL_BUILD-in-the-PREDEFINED_TARGETS_FOLDER.patch
2016-03-22 09:34Taylor Braun-JonesNote Added: 0040739
2016-03-22 10:12Brad KingNote Added: 0040740
2016-06-10 14:21Kitware RobotNote Added: 0041219
2016-06-10 14:21Kitware RobotStatusresolved => closed

Notes
(0038785)
Brad King   
2015-05-20 14:06   
If anyone works on this I think it should be a DIRECTORY property because we generate a .sln for each CMakeLists.txt file that has a project(). The property value for the directory corresponding to this CMakeLists.txt would determine that .sln's first project. This could be implemented with a special case in the .sln writing code rather than trying to adjust the overall project sorting.
(0038786)
Davy Durham   
2015-05-20 15:25   
Don't directory properties "leak" out into subsequent calls to add_subdirectory()? At least, I think I've experienced that.
(0038787)
Brad King   
2015-05-21 08:38   
Only a few specific properties like COMPILE_DEFINITIONS propagate into subdirectories automatically.
(0038791)
Davy Durham   
2015-05-21 11:08   
If you think no work will be soon started on a feature like this, I would be willing to attempt it (following your direction above) and attach a patch file. Advisable?
(0038792)
Brad King   
2015-05-21 11:23   
Re 0015578:0038791: Yes, please. Take a look at CONTRIBUTING.rst at the top of the source tree to the preferred contribution path.

As for the implementation, take a look at OrderedTargetDependSet and the comparison operator implemented here:

 http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmGlobalVisualStudioGenerator.cxx;hb=v3.2.2#l827 [^]

One could refactor TargetCompare to take the name of the "first" target as a constructor argument and simply default it to ALL_BUILD.
(0040705)
Davy Durham   
2016-03-16 15:47   
FWIW I submitted a patch to cmake-developers (subject: "Re: [cmake-developers] Startup Project Configuration [mantis 15578]" on 6/3/2015) which worked for me.

The response was that it needed a unit test to verify the results, but I was/am at a complete loss on how to do that.

I'd still like to see the feature in the cmake mainline. But for now I'm using CreateLaunchers from https://github.com/rpavlik/cmake-modules [^] . It needed a little TLC to work with newer cmake.
(0040706)
Brad King   
2016-03-16 16:04   
Re 0015578:0040705: Yes, that thread was waiting for another response from you. Also you never posted the patch with the latest round of corrections. Please revive the thread over there if you want to see integration move forward. Please also rebase the patch on 'master' in case there are any new conflicts.
(0040729)
Taylor Braun-Jones   
2016-03-18 12:41   
I've revived that thread with an updated patch.
(0040738)
Brad King   
2016-03-22 07:59   
Re 0015578:0040729: Thanks. After further revisions discussed in the thread and to fix nightly testing problems, the patch has landed:

 VS: Add option to choose the `.sln` startup project
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=78ec0461 [^]
(0040739)
Taylor Braun-Jones   
2016-03-22 09:34   
I did some more thorough testing and ran into an issue when
USE_FOLDERS is enabled. The problem is actually the same one affecting
the ALL_BUILD target that is preventing it from being grouped with the
PREDEFINED_TARGETS_FOLDER as it should be. It's not actually the first
target in a .sln file that is treated as the default startup project,
but rather the first _fully defined target_. See this SO comment
thread:

http://stackoverflow.com/questions/694730/why-is-set-as-startup-option-stored-in-the-suo-file-and-not-the-sln-file#comment40597475_1808352 [^]

The solution is to just list all folders in the .sln file first (patch
0002). With the fix in patch 0002, ALL_BUILD can then be put in
PREDEFINED_TARGETS_FOLDER (patch 0003).
(0040740)
Brad King   
2016-03-22 10:12   
Re 0015578:0040739: Thanks. I see your post about this in the thread:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/13356/focus=16073 [^]

I'll follow up over there because the dev list is the preferred place for contributions and the main issue here is already resolved.
(0041219)
Kitware Robot   
2016-06-10 14:21   
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.