[Scons-dev] SCons missing dependencies (not rebuilding files when they need to be)
Bill Deegan
bill at baddogconsulting.com
Fri May 6 11:40:28 EDT 2016
Likely the issue is that there is no source for the command that creates
result.txt.
If I'm reading your logic correctly I think it should be '$PRINT_TASK"
As you can see from the --tree=prune result.txt doesn't depend on anything.
so there's no need to rerun it.
Also try running with --debug=explain
-Bill
On Fri, May 6, 2016 at 11:26 AM, Krzysztof Trzciński <
christopher.trzcinski at gmail.com> wrote:
> No. I am saying it behaves the same way in both versions.
>
> $ scons use_task=0 --tree=prune
> scons: Reading SConscript files ...
> 1/print
> 2/print
> scons: done reading SConscript files.
> scons: Building targets ...
> scons: `1/print' is up to date.
> +-1/print
> +-1/print.o
> | +-1/print.cc
> | | +-#include <iostream>
> int main()
> {
> std::cout << "Printing " << 1 << std::endl;
> return 0;
> }
>
> | +-/usr/bin/g++
> +-/usr/bin/g++
> scons: `2/print' is up to date.
> +-2/print
> +-2/print.o
> | +-2/print.cc
> | | +-#include <iostream>
> int main()
> {
> std::cout << "Printing " << 2 << std::endl;
> return 0;
> }
>
> | +-/usr/bin/g++
> +-/usr/bin/g++
> scons: `result.txt' is up to date.
> +-result.txt
> scons: done building targets.
>
> $ scons use_task=1 --tree=prune
> scons: Reading SConscript files ...
> 1/print
> 2/print
> scons: done reading SConscript files.
> scons: Building targets ...
> scons: `1/print' is up to date.
> +-1/print
> +-1/print.o
> | +-1/print.cc
> | | +-#include <iostream>
> int main()
> {
> std::cout << "Printing " << 1 << std::endl;
> return 0;
> }
>
> | +-/usr/bin/g++
> +-/usr/bin/g++
> scons: `2/print' is up to date.
> +-2/print
> +-2/print.o
> | +-2/print.cc
> | | +-#include <iostream>
> int main()
> {
> std::cout << "Printing " << 2 << std::endl;
> return 0;
> }
>
> | +-/usr/bin/g++
> +-/usr/bin/g++
> scons: `result.txt' is up to date.
> +-result.txt
> scons: done building targets.
>
>
> P.S. Yes, I noticed I've broadcasted my password as soon as I saw it come
> back to me from list. Already have changed it.
>
> On 6 May 2016 at 13:43, Bill Deegan <bill at baddogconsulting.com> wrote:
>
>>
>>
>> On Fri, May 6, 2016 at 8:36 AM, Bill Deegan <bill at baddogconsulting.com>
>> wrote:
>>
>>> Greetings,
>>>
>>> The scons dev mailing list is intended for discussion development of
>>> scons itself.
>>>
>>> Bugs should be initially discussed on the users mailing list. Thus I'm
>>> cc'ing that list. Please move the discussion there.
>>>
>>> Thanks,
>>> Bill
>>>
>>> On Fri, May 6, 2016 at 3:30 AM, Krzysztof Trzciński <
>>> christopher.trzcinski at gmail.com> wrote:
>>>
>>>> Below is fully self contained SConstruct showing (I think) a bug
>>>> (interesting bits at the end):
>>>>
>>>> env = Environment(tools=['default', 'textfile'])
>>>>
>>>> # That bit is not that important.
>>>> # It just creates to programs, one of which
>>>> # prints "1" and the other prints "2".
>>>> # It just emulates having i.e. two versions of compiler
>>>> # (in different directories).
>>>> prints = []
>>>> for num in (1,2):
>>>> printcc = env.Textfile(
>>>> '{0}/print.cc'.format(num),
>>>> [(
>>>> '#include <iostream>\n'
>>>> 'int main()\n'
>>>> '{{\n'
>>>> ' std::cout << "Printing " << {0} << std::endl;\n'
>>>> ' return 0;\n'
>>>> '}}\n'
>>>> ).format(num),],
>>>> )
>>>>
>>>> prints.extend(env.Program(
>>>> '{0}/print'.format(num),
>>>> printcc
>>>> ))
>>>>
>>>> for p in prints:
>>>> print p.path
>>>>
>>>>
>>>> # Here starts the important bit.
>>>> # This is not actual use case, actual use case for me was
>>>> # changing compiler version (by changing base directory
>>>> # of all my tools to newer version).
>>>> # For ease of use this takes `use_task` argument to select
>>>> # which "compiler version" to use.
>>>>
>>>> env['PRINT_TASK'] = prints[int(ARGUMENTS['use_task'])]
>>>>
>>>> # And now the build command dependent on
>>>> # on "compiler".
>>>>
>>>> result = env.Command(
>>>> 'result.txt',
>>>> [],
>>>> '$PRINT_TASK > $TARGET'
>>>> )
>>>>
>>>> Default(prints+result)
>>>>
>>>> Now let's see how it works:
>>>>
>>>> # Let's use "older compiler":
>>>>
>>>> $ scons use_task=0
>>>> scons: Reading SConscript files ...
>>>> 1/print
>>>> 2/print
>>>> scons: done reading SConscript files.
>>>> scons: Building targets ...
>>>> Creating '1/print.cc'
>>>> g++ -o 1/print.o -c 1/print.cc
>>>> g++ -o 1/print 1/print.o
>>>> Creating '2/print.cc'
>>>> g++ -o 2/print.o -c 2/print.cc
>>>> g++ -o 2/print 2/print.o
>>>> 1/print > result.txt
>>>> scons: done building targets.
>>>>
>>>> $ cat result.txt
>>>> Printing 1
>>>>
>>>> # All built fine and looking good.
>>>>
>>>> # Now let's use "newer compiler".
>>>> # This one should produce "2" in result.txt
>>>>
>>>> $ scons use_task=1
>>>> scons: Reading SConscript files ...
>>>> 1/print
>>>> 2/print
>>>> scons: done reading SConscript files.
>>>> scons: Building targets ...
>>>> scons: `1/print' is up to date.
>>>> scons: `2/print' is up to date.
>>>> scons: `result.txt' is up to date.
>>>> scons: done building targets.
>>>>
>>>> $ cat result.txt
>>>> Printing 1
>>>>
>>>> # Yet it doesn't! It says it is already up to date!
>>>> # HERE it went wrong.
>>>>
>>>> # Some sanity checks to verify it is incorrectly
>>>> # reporting state.
>>>> # Let's just check if building that file first with
>>>> # use_task=1 gives us "2" in file.
>>>> # First remove result.txt to force build.
>>>>
>>>> $ rm result.txt
>>>>
>>>> # Then build with "new compiler".
>>>>
>>>> $ scons use_task=1
>>>> scons: Reading SConscript files ...
>>>> 1/print
>>>> 2/print
>>>> scons: done reading SConscript files.
>>>> scons: Building targets ...
>>>> scons: `1/print' is up to date.
>>>> scons: `2/print' is up to date.
>>>> 2/print > result.txt
>>>> scons: done building targets.
>>>>
>>>> $ cat result.txt
>>>> Printing 2
>>>>
>>>> # And this time it executed new compiler
>>>> # which gave expected result of "2".
>>>>
>>>> # If I switch back to old one it again reports
>>>> # result to up to date incorrectly:
>>>>
>>>> $ scons use_task=0
>>>> scons: Reading SConscript files ...
>>>> 1/print
>>>> 2/print
>>>> scons: done reading SConscript files.
>>>> scons: Building targets ...
>>>> scons: `1/print' is up to date.
>>>> scons: `2/print' is up to date.
>>>> scons: `result.txt' is up to date.
>>>> scons: done building targets.
>>>>
>>>> So bottom line seems to be that SCons is missing out on dependencies.
>>>> When a substition value is a file node it seems to only look at `
>>>> node.name`, not whole `node.path`, causing incorrect rebuilds.
>>>>
>>>> I have checked and it seems to behave that way on 2.5.0 version
>>>> (everyday we got stuck on 2.1.0).
>>>>
>>>> Is this a bug? If not what is the explanation of this behaviour?
>>>>
>>>
>> So you're saying this works on 2.1.0 and not on 2.5.0?
>> Can you paste the output of:
>> scons --tree=prune
>> For each argument value?
>>
>> -Bill
>> p.s. posting your mailman password publically as you did in you initial
>> posting at the end is not a god idea. If you can change it, I'd recommend
>> you do.
>>
>> _______________________________________________
>> Scons-dev mailing list
>> Scons-dev at scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>>
>
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20160506/72bfdb86/attachment.html>
More information about the Scons-dev
mailing list