[Scons-users] buggy AddOption behavior

Matthew Dennis mdennis at epochlabs.com
Wed Sep 24 16:23:45 EDT 2014


With the following structure:

scons_bug
|-- SConscript
|-- SConstruct
|-- t0
|   |-- SConscript
|   `-- t0.cpp
`-- t1
    |-- SConscript
    `-- t1.cpp

where SConscript is:

AddOption(
    '--out',
    nargs=1,
    dest='out',
    action='store',
    help='directory to build into',
    default='out'
)
SConscript('SConscript', variant_dir=GetOption('out'), duplicate=0)

and SConscript is:

env = Environment()
Export('env')
SConscript('t0/SConscript')
SConscript('t1/SConscript')
Default(['t0', 't1'])

and t0/SConscript is:

Import('env')
t0_env = env.Clone()
t0_env.Program('t0', ['t0.cpp'])

and t1/SConscript is:

Import('env')
t1_env = env.Clone()
t1_env.Program('t1', ['t1.cpp'])

If I run "scons t0" (or "scons t1") I get the expected output (only the
specified target is build and the output is built in "out").

"scons t0" output:
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
scons: building associated VariantDir targets: out/t0
g++ -o out/t0/t0.o -c t0/t0.cpp
g++ -o out/t0/t0 out/t0/t0.o
scons: `t0' is up to date.
scons: done building targets.

However, if I run "scons --out foo t0" scons correctly picks up "foo" as
the specified output directory (e.g. accessible via GetOption and output is
indeed directed toward the "foo" directory).  The problem is that it *also*
appears to pick up "foo" as a target and hence builds the entire world
before then building the specified target (which has actually already been
built because the entire world was built so it just prints that it is up to
date).  In the real project "the world" is much much larger than t0 and t1
of course.

"scons --out foo t0" output:
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
scons: building associated VariantDir targets: foo
g++ -o foo/t0/t0.o -c t0/t0.cpp
g++ -o foo/t0/t0 foo/t0/t0.o
g++ -o foo/t1/t1.o -c t1/t1.cpp
g++ -o foo/t1/t1 foo/t1/t1.o
scons: building associated VariantDir targets: foo/t0
scons: `t0' is up to date.
scons: done building targets.

Notice that it builds "foo" as a target.  If you change it to "scons t0
--out foo" the same thing happens except it builds "foo/t0" first and then
builds "foo".

Interestingly enough though if you run "scons --out=foo t0" (notice the =
in the command) the behavior is correct (only t0 is built and it is built
into the directory "foo").

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).

I had a brief discussion about this in IRC and was asked to post it to the
list, so ... thoughts?  bug?

I'd really like something better than "hey entire team please remember to
always use = when specifying scons options or suffer the pain" ...

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).

Thanks,

Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20140924/0145347f/attachment-0001.html>


More information about the Scons-users mailing list