View Issue Details Jump to Notes ] Print ]
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.
TagsNo tags attached.
Attached Filespatch file icon 0001-fixup-VS-Add-option-to-choose-the-.sln-startup-proje.patch [^] (2,953 bytes) 2016-03-22 09:34 [Show Content]
patch file icon 0002-VS-Fix-default-target-support-for-targets-nested-ins.patch [^] (3,145 bytes) 2016-03-22 09:34 [Show Content]
patch file icon 0003-Put-ALL_BUILD-in-the-PREDEFINED_TARGETS_FOLDER.patch [^] (1,385 bytes) 2016-03-22 09:34 [Show Content]

 Relationships
related to 0002919closedBill Hoffman commnd to set the Startup Project in MSVC 
has duplicate 0015931closedKitware Robot Change the StartUp-Solution by Value 

  Notes
(0038785)
Brad King (manager)
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 (reporter)
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 (manager)
2015-05-21 08:38

Only a few specific properties like COMPILE_DEFINITIONS propagate into subdirectories automatically.
(0038791)
Davy Durham (reporter)
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 (manager)
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 (reporter)
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 (manager)
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 (reporter)
2016-03-18 12:41

I've revived that thread with an updated patch.
(0040738)
Brad King (manager)
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 (reporter)
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 (manager)
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 (administrator)
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.

 Issue History
Date Modified Username Field Change
2015-05-20 13:10 Davy Durham New Issue
2015-05-20 14:03 Brad King Relationship added related to 0002919
2015-05-20 14:06 Brad King Note Added: 0038785
2015-05-20 15:25 Davy Durham Note Added: 0038786
2015-05-21 08:38 Brad King Note Added: 0038787
2015-05-21 11:08 Davy Durham Note Added: 0038791
2015-05-21 11:23 Brad King Note Added: 0038792
2016-03-15 16:54 Nils Gladitz Relationship added has duplicate 0015931
2016-03-16 15:47 Davy Durham Note Added: 0040705
2016-03-16 16:04 Brad King Note Added: 0040706
2016-03-18 12:41 Taylor Braun-Jones Note Added: 0040729
2016-03-22 07:59 Brad King Note Added: 0040738
2016-03-22 07:59 Brad King Status new => resolved
2016-03-22 07:59 Brad King Resolution open => fixed
2016-03-22 07:59 Brad King Fixed in Version => CMake 3.6
2016-03-22 07:59 Brad King Target Version => CMake 3.6
2016-03-22 09:34 Taylor Braun-Jones File Added: 0001-fixup-VS-Add-option-to-choose-the-.sln-startup-proje.patch
2016-03-22 09:34 Taylor Braun-Jones File Added: 0002-VS-Fix-default-target-support-for-targets-nested-ins.patch
2016-03-22 09:34 Taylor Braun-Jones File Added: 0003-Put-ALL_BUILD-in-the-PREDEFINED_TARGETS_FOLDER.patch
2016-03-22 09:34 Taylor Braun-Jones Note Added: 0040739
2016-03-22 10:12 Brad King Note Added: 0040740
2016-06-10 14:21 Kitware Robot Note Added: 0041219
2016-06-10 14:21 Kitware Robot Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team