[Scons-users] bug with AddOption?

[Gabe Black]

The two AddOption calls look like this:

AddOption('--linker', action='store', default=None, choices=linker_options,
          help=f'Select which linker to use ({", ".join(linker_options)})')
AddOption('--gold-linker', action='store_const', const='gold',
dest='linker',
          help='Use the gold linker. Deprecated: Use --linker=gold')

We aren't using nargs, although I did consider that and look into it. It
didn't look promising, since according to the docs this *should* work like
I would expect, and using nargs adds some wrinkles to how the arguments are
processed (like putting a single argument in a list).

The error I get when passing --gold-linker followed by another -- option
looks like this:

scripts/build_gem5 --gold-linker --ignore-style build/ARM/gem5.opt
...
usage: build_gem5 [--gold-linker GOLD_LINKER] [--linker LINKER]

where build_gem5 is just a thin wrapper around the actual call to scons.
You can see that it expects both --gold-linker and --linker to each have an
argument, where --linker is supposed to but --gold-linker is not. I think
they may be getting mixed together since they both set the "linker" option,
or maybe something isn't processing "store_const" properly.

I definitely can see and appreciate how processing these arguments,
variable settings, and targets is difficult, and perhaps impossible to get
completely right. We can work around the --linker=gold issue fairly easily,
which I think we'll need to given how hard this is probably to fix.

We can avoid the --gold-linker problem by not using that option, and we do
mark it as deprecated since it has been supplanted by the --linker option.
It's a little more of a landmine, since if it has a non -- after it, then
it *seems* to work as expected, and will just do weird things if there's
another option. I think that's how it snuck through our testing initially,
only cropping up now that I've been changing a command line in one of our
scripts. This also feels a bit more like a regular old boring bug, rather
than an ambiguous or self contradictory problem like the "--linker gold"
situation.

Given that even if SCons fixed this bug *right now* it would be a long time
before all of our possible users had the fix and we could assume the
correct behavior, so it will be something we need to accomodate for the
near future no matter what. I wanted to make sure you were aware of it so
it could eventually get fixed, and in case I was doing something silly and
there was no bug :-)

Thanks!
Gabe

On Thu, Apr 28, 2022 at 2:21 PM Mats Wichmann <mats at wichmann.us> wrote:

> On 4/28/22 15:04, Gabe Black wrote:
> > There seems to also be another problem here as well, although this one
> > might be a usage error on my part. It looks like if you use the --linker
> > option, you also have to use it in --linker=gold form, and can't use it
> > as two arguments, ie --linker gold. I think both *should* work, so this
> > might be another symptom of the first problem.
>
> I didn't get a chance to digest the first question as I'm in between
> stuff, but I definitely recognize this one.
>
> I spent some time tearing my hair out over the problem with the option
> handling a while back, and there are a whole bunch of bugs filed on it
> from over the years.  The brief summary: yup, it's broken.  Fixing it
> isn't easy (or it would have been done).
>
> If you're going to reliably use option-argument forms, do use the
> --foo=bar style. Sadly that can't be enforced from the Python side,
> users just have to get used to doing that.  If you want to use
> multiple-option-arguments, use --foo=bar1,bar2, collect the single
> argument, and process it into two yourself.
>
> ===
>
>
> Fundamentally, there's a conflict.
>
> SCons thinks a command line is:
>
> scons [variables=values]  [--arguments]  [targets]
>
> When it starts up it harvests these, because some have to be available
> for use in SConscripts - command-line targets and variables both are
> supposed to be available for SConscripts to poke around in.  It proceses
> the arguments it knows, and stashes the rest that looks like an argument
> in case those get defined later.  Variables are anything with an = in
> them that wasn't taken out by argument processing.  And the rest, the
> free-standing words, are collected as targets - you can probably see
> where this is going - your "gold" got collected as a target, and
> disassociated from the deferred --linker..
>
> *Now* we process SConscripts, and somewhere there we see an AddOption
> defining --linker, so we can handle that... oops, its too late, its
> option-arg is already in $ COMMAND_LINE_TARGETS .
>
> Can't change the order of things, because then variables and targets
> wouldn't be available to SConscripts, so it's not simple.
>
> _______________________________________________
> 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/20220428/e783b057/attachment-0001.htm>