[Scons-users] buggy AddOption behavior

[Matthew Dennis]

As described in the original email, that does indeed produce the correct
results.  The complaint is that if you do it without the = it does entirely
the wrong thing with no warning.

On Wed, Sep 24, 2014 at 4:05 PM, William Blevins <wblevins001 at gmail.com>
wrote:

> 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
>>
>>
> _______________________________________________
> 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/fe2e37b6/attachment-0001.html>