[Scons-users] buggy AddOption behavior

[William Blevins]

Try --out=foo
On Sep 24, 2014 4:56 PM, "Matthew Dennis" <mdennis at epochlabs.com> wrote:

> 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
>
>
>
>
> _______________________________________________
> 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/6dbf6984/attachment.html>