Hi Gregor, I know you are probably busy with other things, but do you see anything in the discussion so far that should prevent an implementation attempt? I don't have a whole lot of time available to work on this either, so progress will probably be slow with me squeezing in work here and there, so I don't think there will be a review burden soon.
Thanks, Steven On Sun, Oct 8, 2017 at 1:18 PM, Steven Velez <sbv1...@gmail.com> wrote: > After spending some time trying to figure out how to affect the build > "destination", it seems that destinations associated with a given > scheme are not influenced by anything beyond the targets referenced as > build targets for the scheme. In other words, if a scheme builds an > iOS target, then the iOS destinations/devices/simulators will be > present in the UI, and if it references a MacOS target, then the > active computer will be available in the destinations UI. > > The options available in the scheme proper seem to be similar in > either case, and the proposal so far is fairly agnostic to specific > options, so I think the current proposal stands without modification > in this respect. Does this seem like a reasonable statement? > > This investigation did make me realize that each scheme can specify > building more than one target, so I would revise my statement that the > last target referencing a given scheme name should "win". Instead, I > think each target should be built by the given scheme, and the union > of settings provided by each target should be present in the scheme. > If multiple targets indicate a similar setting, then in this case, the > last setting should win, and this should print a warning... but if > order of processing the schemes/targets cannot match source order, > then perhaps it should be noted that what is "last" cannot be > guaranteed.... > > Thanks, > Steven > > > On Thu, Oct 5, 2017 at 9:26 AM, Steven Velez <sbv1...@gmail.com> wrote: >> 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
