[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