[Scons-users] Why is resetting user-defined options with SetOption forbidden?

[Bill Deegan]

I'm looking at how hard it would be to check if the option is a user added
option, and then allow those to be changed.
All user(sconscript) added options are in one option group..
-Bill

On Sun, Mar 12, 2017 at 2:01 PM, Andrew C. Morrow <andrew.c.morrow at gmail.com
> wrote:

>
>
> On Fri, Mar 10, 2017 at 2:27 AM, Jean-Baptiste Lab <
> jeanbaptiste.lab at gmail.com> wrote:
>
>> On 2017-03-09 20:06, Andrew C. Morrow wrote:
>>
>>
>> Hi -
>>
>> I'd like to be able to rewrite the value of an option I've defined with
>> AddOption, but SetOption appears to forbid this except for certain
>> intrinsic SCons options. This seems quite restrictive. I have many options
>> of this form:
>>
>>     AddOption('build-fast',
>>         choices=['on', 'off', 'auto'],
>>         const='on',
>>         default='auto',
>>         help='faster dependency checking',
>>         nargs='?',
>>         type='choice',
>>     )
>>
>> The 'auto' value is intended to allow the system to decide whether 'on'
>> or 'off' is appropriate, given the value of other options. However, the end
>> result is that it should hold the value 'on' or 'off'. So, ideally, I'd
>> later write:
>>
>> if GetOption('build-fast') == 'auto':
>>     if <conditions>:
>>         SetOption('build-fast') = 'on'
>>     else
>>         SetOption('build-fast') = 'off'
>>
>> That way, once I've done this normalization step, I can just ask anywhere
>> I need:
>>
>> if GetOption('build-fast') == 'on':
>>     do-stuff
>>
>> However, it seems that this is forbidden by SCons internally, even for
>> user-defined options, failing with a message like:
>>
>> scons: *** This option is not settable from a SConscript file: build-fast
>>
>> As a result, I need to hoist the option value into a variable, and
>> normalize that, then Export it for others to see and use instead of the
>> option value:
>>
>> build_fast = GetOption('build-fast')
>> if build_fast == 'auto':
>>     build_fast = 'on' if conditions else 'off'
>> Export('build_fast')
>>
>> This is unfortunate, since now the value of GetOption('build-fast')
>> isn't canonical, this exported state variable is instead, they vary in
>> their values, and it is easy to query the wrong one yielding different
>> results.
>>
>> I understand that some intrinsic SCons options may not make sense to be
>> reset, but is there an explicit reason that it cannot be done for user
>> defined options?
>>
>> Thanks,
>> Andrew
>>
>>
>>
>>
>> _______________________________________________
>> Scons-users mailing listScons-users at scons.orghttps://pairlist4.pair.net/mailman/listinfo/scons-users
>>
>> Hi Andrew,
>>
>> Instead of exporting the variables individually through an Export() call,
>> wouldn't it be possible to set them as SCons Environment() variables and
>> then export that instead?
>>
>> I'm thinking something roughly like this in your SConstruct (not tested,
>> email coding!):
>>
>> options = Environment()
>>
>> options['build_fast'] = GetOption('build-fast')
>>
>> options['other_option'] = GetOption('other_option')
>>
>> ... more options ...
>>
>> Export('options')
>>
>> I know it's not ideal, but at least it would gather all the
>> (non-SetOption-able) options in one place and everybody can use that...
>>
>> I can see the rationale as to why only some options are SetOption-able,
>> but looking at the code, it uses a whitelist of options that can be set,
>> which works but is very restrictive, maybe a blacklist of non-settable
>> options would be better? Let's see if any SCons core people can chime in on
>> that...
>>
>>
>> Hope this helps,
>>
>>
>> JB
>>
>
> Thanks for the suggestion, that is definitely one approach. Right now, we
> actually have both approaches (value set in the Environment, or Export'ed
> python variable) in our build system, which is not ideal. However, both
> approaches still suffer from the same issue - if someone forgets that the
> Option value is non-canonical and queries that instead of the normalized
> value, they will get the wrong answer.
>
> I do like the idea of reversing the semantics of SetOption's checking.
> Perhaps another approach would be to add a 'mutable' attribute to Options,
> and only permit SetOption calls to succeed if the option has been tagged
> mutable? That would avoid the possibility of the blacklist becoming
> obsolete.
>
> Do any of the core SCons developers have thoughts?
>
> Thanks,
> Andrew
>
>
>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20170312/7bca208a/attachment.html>