[Scons-users] buggy AddOption behavior

[Matthew Dennis]

Thanks.  I filed 2977 to track it.

For the time being we are now checking every argv element at the top of
SConstruct to make sure if it is the --out param that it is properly
formatted and just bail out with an error message if not.  It is not ideal,
but should prevent completely unexpected behavior from slipping by
silently.  If this ends up not being good enough (or if other options cause
problems), I'll implement your wrapper script suggestion.

On Wed, Sep 24, 2014 at 5:17 PM, Dirk Bächle <tshortik at gmx.de> wrote:

>  Hi Matthew,
>
> On 24.09.2014 22:23, Matthew Dennis wrote:
>
> With the following structure:
>
>  [...]
>  For the command "scons --out=foo t0" optparse correctly returns {'out':
> 'foo'} as the options and ['t0'] as the args (it also does it correctly for
> all the other various ordering/permutations).  That seems to imply that
> scons looks for the targets from the command line itself, outside of
> optparse (but I haven't looked at the code).
>
>   yes, it does. There are several places where the options get parsed,
> and I think your example can indeed be declared a bug. Things seem to go
> wrong in ll. 959 of "engine/SCons/Scrip/Main.py":
>
>     # That should cover (most of) the options.  Next, set up the variables
>     # that hold command-line arguments, so the SConscript files that we
>     # read and execute have access to them.
>     targets = []
>     xmit_args = []
>     for a in parser.largs:
>         if a[:1] == '-':
>             continue
>         if '=' in a:
>             xmit_args.append(a)
>         else:
>             targets.append(a)
>
> Unfortunately, the fix isn't a simple one-liner...if done properly. As you
> correctly state below, boolean arguments are a problem...so one would have
> to compare the option "type" (string or bool) for each found argument, and
> then decide whether a following argument is required that has to get
> skipped while compiling the list of targets.
> I'm also not sure how to handle options that have a callback method
> defined...so quite some work ahead there.
>
>   I had a brief discussion about this in IRC and was asked to post it to
> the list, so ... thoughts?  bug?
>
>   Bug, I say. Could you possibly open an issue ticket for this in our bug
> tracker at scons.tigris.org?
>
>   I'd really like something better than "hey entire team please remember
> to always use = when specifying scons options or suffer the pain" ...
>
>   Would a wrapper script be an option, where you parse the arguments with
> optparse yourself first, and then call SCons from there...always using the
> working "--out=xyz" syntax?
>
>   If it can't be "fixed" (i.e. if = is required to get the correct
> behavior) can we at least have scons raise an error that no = was used when
> specifying an option (clearly doesn't work for boolean args but with
> nargs=1 in AddOption it should be non-ambiguous).
>
> I think if we would be able to warn the user, this would include the fix
> itself in a way. ;)
>
> Best regards,
>
> Dirk
>
>
> _______________________________________________
> 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/20140924/9e3c835a/attachment-0001.html>