[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