[Scons-dev] SCons missing dependencies (not rebuilding files when they need to be)

Krzysztof Trzciński christopher.trzcinski at gmail.com
Fri May 6 11:49:28 EDT 2016


That is not the problem.

Replace `$PRINT_TASK` with `$SHCXX` (or any other pre-defined thing).

Note that replacing

 '$PRINT_TASK > $TARGET'

with

 '$PRINT_TASK.path > $TARGET'

It suddenly starts to work.
Same thing happens if I replace

env['PRINT_TASK'] = prints[int(ARGUMENTS['use_task'])]

with

env['PRINT_TASK'] = prints[int(ARGUMENTS['use_task'])].path

or

env['PRINT_TASK'] = str(prints[int(ARGUMENTS['use_task'])])



The is analogous to changing compiler version. I.e. pointing to a different
compiler binary from a different directory, which is exactly how I stumbled
upon this.
I changed my Environments CC, SHCXX, and others to point to newer version
only to discover that SCons decided that everything is up to date.

That doesn't sound correct.



On 6 May 2016 at 16:40, Bill Deegan <bill at baddogconsulting.com> wrote:

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


More information about the Scons-dev mailing list