[Scons-users] buggy AddOption behavior

[Dirk Bächle]

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

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