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

Reply via email to