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

Bill Deegan bill at baddogconsulting.com
Fri May 6 12:17:34 EDT 2016


If I change:
result = env.Command(
    'result.txt',
    '',
    '$PRINT_TASK > $TARGET')

To:
result = env.Command(
    'result.txt',
    "$PRINT_TASK",
    '$PRINT_TASK > $TARGET')

It does work as expected.
However.. as you said it should still work as it works with other
${PRINT_TASK.path}

However as you can see from --tree=prune, binaries always depend on the
compiler used to compile them so changing that should cause a rebuild.

I'll keep digging at your example.
-Bill


On Fri, May 6, 2016 at 11:49 AM, Krzysztof Trzciński <
christopher.trzcinski at gmail.com> wrote:

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


More information about the Scons-dev mailing list