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

[Jean-Baptiste Lab]

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 list
> Scons-users at scons.org
> https://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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20170310/537664bb/attachment.html>