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

[Andrew C. Morrow]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20170312/09118b3f/attachment.html>