[cmake-developers] Extending XCode scheme generation support

[Martin Sander]

Sorry for creating a new thread, I do not know how to respond to a previous
thread as a new member.

Is there any progress on the xcode schemes?

If not, I’ll give it a try and change cmXCodeScheme.cxx according to
https://cmake.org/get-involved

I’m especially interested in changing the “Executable” and the Flags on the
xcode “Diagnostics” tab



Martin
-- 

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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Extending XCode scheme generation support

[Steven Velez]

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  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  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  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: 

Re: [cmake-developers] Extending XCode scheme generation support

[Steven Velez]

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  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  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

Re: [cmake-developers] Extending XCode scheme generation support

[Steven Velez]

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  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

Re: [cmake-developers] Extending XCode scheme generation support

[Steven Velez]

Hi guys,

Any thoughts on this?

TL;DR Version:

We can add some target properties that the Xcode generator uses to
customize schemes:

* XCODE_SCHEME_NAME
* XCODE_SCHEME_LAUNCH_OPTS
* XCODE_SCHEME_LAUNCH_ADTL_OPTS
* XCODE_SCHEME_LAUNCH_RUNNABLE
* XCODE_SCHEME_LAUNCH_ARGUMENTS
* XCODE_SCHEME_LAUNCH_ENVIRONMENT

OR

The configure_file function can be augmented to be runnable during
generation so that it can process generator expressions which are
defined to support this scheme-customization workflow.

Thanks,
Steven


On Thu, Sep 21, 2017 at 9:36 PM, Steven Velez  wrote:
> Hello Again,
>
> Sorry for the delay.  After some consideration and investigation, I have the
> following two proposals:
>
> # 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.  Scheme
> files are persisted as xml, and currently, each scheme file contains six
> elements directly underneath the root element which correspond to each of the
> [scheme actions](http://help.apple.com/xcode/mac/8.3/#/devd9c8382e7) available
> in the scheme editor.
>
> To this end, with one exception, the specialized properties defined for this
> purpose will follow the convention `XCODE_SCHEME__` 
> where
> `` may be one of `BUILD`, `TEST`, `LAUNCH`, `PROFILE`, `ANALYZE`,
> `ARCHIVE` and `` will be appropriate to the particular item being
> configured and detailed further below.  The exception to this convention is 
> the
> `XCODE_SCHEME_NAME` property which will be used to override the default name 
> of
> the generated scheme that by default matches the name of the target it is
> associated to. It can even be set to the empty string in order to completely
> disable scheme generation for select targets.
>
> These properties will be ignored by all generators but the Xcode generator.
>
> ## CONFIGIDs
> Being unable to find official, public documentation on the design and format 
> of
> xcode scheme files, experimental analysis has revealed that that there are
> approximately three classes of configuration methods used in each action's xml
> element.  The first class of options are specified as attributes of the 
> action's
> xml element.  The second class of options are specified as elements providing
> name/value pairs via attributes and are are children of an `AdditionalOptions`
> element in the action element, and the final class is everything else and 
> which
> has a different format in each case.
>
> This proposal is primarily concerned with extending and controlling the
> configuration of the Launch action and therefore includes CONFIGIDs that apply
> to that action, though it is possible and in some cases likely that they will
> have general utility in most other actions.  These are as follows:
>
> * `OPTS` - Properties with this config id will be a CMake list of name/value
> pairs where the names and values are strings separated by the first embedded
> equals sign. Once parsed, the names will be used to identify xml attributes to
> set on the action element and the values will of course be the values set on
> those attributes.
> * `ADTL_OPTS` - Like with the `OPTS` config id, this will be a list of
> name/value pairs.  However, the names and values will be used to define xml
> elements of the form ` isEnabled="YES"/>` which are then added to the `` element
> of the current action.  Note, that there are no provisions for controlling the
> `isEnabled` state of an option besides those programmatic elements of CMake
> which would make it possible to specify (or not) a given additional option.
> It is unclear what the semantic difference is between "options" and
> "additional options" as there is no clear distinction in the Xcode UI.
> * `RUNNABLE` - This is a simple string which can be interpreted as a target
> reference if it matches the name of an executable target in the project, or a
> literal path to an executable on the file system otherwise.  In either case,
> it specifies the executable which will be run when the scheme is active.  When
> no `RUNNABLE` target is specified, the current, default runnable is used.
> * `ARGUMENTS` - Is a CMake list of strings that each define an element of the
> form `` to add to
> the `` element of the current action.  As with
> `ADTL_OPTS`, `isEnabled` cannot be changed. These values are passed to the
> executable specified by `RUNNABLE` as command line arguments.
> * `ENVIRONMENT` - This is similar to `ADTL_OPTS` except the elements created 
> are
> of the form ` isEnabled="YES"/>` and they are added to the `` element
> of the current action.  These values are used to initialize the process
> environment of the executable specified by `RUNNABLE`
>
> ## Unexplored/Unsupported
> Support for scheme action pre and post actions are not part of this proposal
> because it is believed that in order 

Re: [cmake-developers] Extending XCode scheme generation support

[Steven Velez]

Hello Again,

Sorry for the delay.  After some consideration and investigation, I have the
following two proposals:

# 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.  Scheme
files are persisted as xml, and currently, each scheme file contains six
elements directly underneath the root element which correspond to each of the
[scheme actions](http://help.apple.com/xcode/mac/8.3/#/devd9c8382e7) available
in the scheme editor.

To this end, with one exception, the specialized properties defined for this
purpose will follow the convention `XCODE_SCHEME__` where
`` may be one of `BUILD`, `TEST`, `LAUNCH`, `PROFILE`, `ANALYZE`,
`ARCHIVE` and `` will be appropriate to the particular item being
configured and detailed further below.  The exception to this convention is the
`XCODE_SCHEME_NAME` property which will be used to override the default name of
the generated scheme that by default matches the name of the target it is
associated to. It can even be set to the empty string in order to completely
disable scheme generation for select targets.

These properties will be ignored by all generators but the Xcode generator.

## CONFIGIDs
Being unable to find official, public documentation on the design and format of
xcode scheme files, experimental analysis has revealed that that there are
approximately three classes of configuration methods used in each action's xml
element.  The first class of options are specified as attributes of the action's
xml element.  The second class of options are specified as elements providing
name/value pairs via attributes and are are children of an `AdditionalOptions`
element in the action element, and the final class is everything else and which
has a different format in each case.

This proposal is primarily concerned with extending and controlling the
configuration of the Launch action and therefore includes CONFIGIDs that apply
to that action, though it is possible and in some cases likely that they will
have general utility in most other actions.  These are as follows:

* `OPTS` - Properties with this config id will be a CMake list of name/value
pairs where the names and values are strings separated by the first embedded
equals sign. Once parsed, the names will be used to identify xml attributes to
set on the action element and the values will of course be the values set on
those attributes.
* `ADTL_OPTS` - Like with the `OPTS` config id, this will be a list of
name/value pairs.  However, the names and values will be used to define xml
elements of the form `` which are then added to the `` element
of the current action.  Note, that there are no provisions for controlling the
`isEnabled` state of an option besides those programmatic elements of CMake
which would make it possible to specify (or not) a given additional option.
It is unclear what the semantic difference is between "options" and
"additional options" as there is no clear distinction in the Xcode UI.
* `RUNNABLE` - This is a simple string which can be interpreted as a target
reference if it matches the name of an executable target in the project, or a
literal path to an executable on the file system otherwise.  In either case,
it specifies the executable which will be run when the scheme is active.  When
no `RUNNABLE` target is specified, the current, default runnable is used.
* `ARGUMENTS` - Is a CMake list of strings that each define an element of the
form `` to add to
the `` element of the current action.  As with
`ADTL_OPTS`, `isEnabled` cannot be changed. These values are passed to the
executable specified by `RUNNABLE` as command line arguments.
* `ENVIRONMENT` - This is similar to `ADTL_OPTS` except the elements created are
of the form `` and they are added to the `` element
of the current action.  These values are used to initialize the process
environment of the executable specified by `RUNNABLE`

## Unexplored/Unsupported
Support for scheme action pre and post actions are not part of this proposal
because it is believed that in order to support them, target property names will
either have to be excessively cumbersome, or the supported functionality will
need to be excessively specialized and limited.

## Explicit list of properties
When conventions above are expanded to meet the needs of the Launch action, this
results in the following six properties which can be applied to any target.

* `XCODE_SCHEME_NAME`
* `XCODE_SCHEME_LAUNCH_OPTS`
* `XCODE_SCHEME_LAUNCH_ADTL_OPTS`
* `XCODE_SCHEME_LAUNCH_RUNNABLE`
* `XCODE_SCHEME_LAUNCH_ARGUMENTS`
* `XCODE_SCHEME_LAUNCH_ENVIRONMENT`

## Generator Expressions
The properties specified for scheme customization should support generator
expressions.  Most notably, `XCODE_SCHEME_NAME` should recognize `$`,
generating a different scheme file for each configuration.  The value that

Re: [cmake-developers] Extending XCode scheme generation support

[Steven Velez]

Sure.. but I haven't even thought about it much yet.  So when that has
happened, I'll make a more formal proposal.

Thanks,
Steven

On Fri, Sep 15, 2017 at 11:04 AM, Brad King  wrote:

> On 09/15/2017 10:55 AM, Steven Velez wrote:
> > I am assuming that the lack of response indicates that there has not
> > been much thought or interest expressed along this dimension of the
> feature.
> >
> > Would a better way to approach this be to implement a prototype and
> create a WIP MR?
>
> Can you post a more specific proposal here?  E.g. with proposed
> target properties to control it and show some examples.
>
> Thanks,
> -Brad
>
-- 

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

Re: [cmake-developers] Extending XCode scheme generation support

[Brad King]

On 09/15/2017 10:55 AM, Steven Velez wrote:
> I am assuming that the lack of response indicates that there has not
> been much thought or interest expressed along this dimension of the feature.
> 
> Would a better way to approach this be to implement a prototype and create a 
> WIP MR?

Can you post a more specific proposal here?  E.g. with proposed
target properties to control it and show some examples.

Thanks,
-Brad
-- 

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

Re: [cmake-developers] Extending XCode scheme generation support

[Steven Velez]

Hello,

I am assuming that the lack of response indicates that there has not been
much thought or interest expressed along this dimension of the feature.

Would a better way to approach this be to implement a prototype and create
a WIP MR?

Thanks,
Steven


On Fri, Sep 8, 2017 at 12:29 PM, Steven Velez  wrote:

> Hello All,
>
> I recently noticed that 3.9.1 added the ability for the XCode generator to
> also generate scheme files.  This is great as we have been post processing
> generator output to add schemes according to our standards, but are
> discovering various issues with this approach.
>
> However, the current scheme generation appears to lack a couple of
> abilities we would require to replace our custom scripts.  Primarily, we
> need more flexibility over what goes in a particular scheme's launch
> configuration.
>
> I have searched the lists and google to try to find discussions on the
> intended direction of this feature, but could not find any.
>
> If I were to be able to contribute to this, would there be some sort of
> guidance available around how best to expose additional configurability to
> a user?  My immediate thoughts are just that we would need to define/use
> additional target properties, but is there any sort of recommended naming
> convention/scheme or structure that is already existing for mapping sets of
> properties in to the more structured format of scheme xml files.
>
> Thanks,
> Steven
>
-- 

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

[cmake-developers] Extending XCode scheme generation support

[Steven Velez]

Hello All,

I recently noticed that 3.9.1 added the ability for the XCode generator to
also generate scheme files.  This is great as we have been post processing
generator output to add schemes according to our standards, but are
discovering various issues with this approach.

However, the current scheme generation appears to lack a couple of
abilities we would require to replace our custom scripts.  Primarily, we
need more flexibility over what goes in a particular scheme's launch
configuration.

I have searched the lists and google to try to find discussions on the
intended direction of this feature, but could not find any.

If I were to be able to contribute to this, would there be some sort of
guidance available around how best to expose additional configurability to
a user?  My immediate thoughts are just that we would need to define/use
additional target properties, but is there any sort of recommended naming
convention/scheme or structure that is already existing for mapping sets of
properties in to the more structured format of scheme xml files.

Thanks,
Steven
-- 

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