Thanks for the followup Gregor. One thing that concerns me about the property-centric approach is that I can't think of a way to use properties for generating a custom scheme that builds the ALL_BUILD target. I would assume this would run into the same issues and limitations that I have seen in google searches with trying to control the the folder for the ALL_BUILD target with the FOLDER target property (even though this would be a Visual Studio concern). It seems that is addressed now with the *_TARGETS_FOLDER global properties, so maybe an analog can be established?
Regarding sequencing changes, do you mean to come up with a set of smaller logical changes/MRs so that this isn't all dumped at once? If so, I think we could implement XCODE_SCHEME_NAME and a single additional property without generator support, then add generator support, then add the balance of the properties one-by-one. Would that make sense? I have to get more familiar with CMake's testing methodologies to have any comment on that portion. If two targets specify the same schema name, then overwrite/accept latest with a warning? Regarding ios builds or perhaps having multiple build devices (I have seen some hand-made projects with 64-bit and 32-bit desktop clients selectable), then I will also have to get back to you on that. I was thinking the property definitions were generic enough to handle any needs... and I assumed that devices were handles with additional scheme files, but I realize that was a bad assumption. Will try to have that thought out soon. Thanks, Steven On Mon, Oct 2, 2017 at 9:05 AM, Gregor Jasny <gja...@googlemail.com> wrote: > Hello Steven, > > On 9/22/17 3:36 AM, Steven Velez wrote: >> # Property-Centric >> In this proposal, the generation of the scheme files is customized primarily >> by >> a user setting additional, specialized properties on a given target, which >> then >> affect the generation of the scheme files associated with that target. > thank you for working an the scheme proposal. I also believe that the > property-centric approach is better suited and easier to implement than > the file-centrix one. > > Next steps would be to sequence the necessary changes and define test > cases. I could imagine that adding generator-expression support would be > much harder to implement that other things. > > Things that also should be considered are: > * differences between macOS and iOS when generating a scheme > * what should happen if two targets specify the same schema name > > Thanks, > Gregor -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
