View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0015578 | CMake | CMake | public | 2015-05-20 13:10 | 2016-06-10 14:21 | ||||
Reporter | Davy Durham | ||||||||
Assigned To | |||||||||
Priority | normal | Severity | feature | Reproducibility | N/A | ||||
Status | closed | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | |||||||||
Target Version | CMake 3.6 | Fixed in Version | CMake 3.6 | ||||||
Summary | 0015578: Target property that sets Startup Project in MSVC | ||||||||
Description | A 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. | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | 0001-fixup-VS-Add-option-to-choose-the-.sln-startup-proje.patch [^] (2,953 bytes) 2016-03-22 09:34 [Show Content]
0002-VS-Fix-default-target-support-for-targets-nested-ins.patch [^] (3,145 bytes) 2016-03-22 09:34 [Show Content] 0003-Put-ALL_BUILD-in-the-PREDEFINED_TARGETS_FOLDER.patch [^] (1,385 bytes) 2016-03-22 09:34 [Show Content] | ||||||||
Relationships | |||||||||||
|
Relationships |
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. |
Notes |
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 |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |