[Scons-dev] SCons missing dependencies (not rebuilding files when they need to be)
Krzysztof Trzciński
christopher.trzcinski at gmail.com
Mon Jun 27 05:00:36 EDT 2016
Any updates on this? That's quite a nasty bug.
On 6 May 2016 at 22:48, Krzysztof Trzciński <christopher.trzcinski at gmail.com
> wrote:
> First:
>
> $ scons use_task=0 --tree=prune
> scons: Reading SConscript files ...
> 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>
> #include <fstream>
> int main(int argc, char **argv)
> {
> std::cout << "Printing " << 1 << std::endl;
> std::ofstream f(argv[2]);
> f << 1 << "\n";
> 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>
> #include <fstream>
> int main(int argc, char **argv)
> {
> std::cout << "Printing " << 2 << std::endl;
> std::ofstream f(argv[2]);
> f << 2 << "\n";
> return 0;
> }
>
> | +-/usr/bin/g++
> +-/usr/bin/g++
> scons: `2/print.os' is up to date.
> +-2/print.os
> +-[2/print.cc]
> scons: done building targets.
>
> Second
>
> $ scons use_task=1 --tree=prune
> scons: Reading SConscript files ...
> 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>
> #include <fstream>
> int main(int argc, char **argv)
> {
> std::cout << "Printing " << 1 << std::endl;
> std::ofstream f(argv[2]);
> f << 1 << "\n";
> 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>
> #include <fstream>
> int main(int argc, char **argv)
> {
> std::cout << "Printing " << 2 << std::endl;
> std::ofstream f(argv[2]);
> f << 2 << "\n";
> return 0;
> }
>
> | +-/usr/bin/g++
> +-/usr/bin/g++
> scons: `2/print.os' is up to date.
> +-2/print.os
> +-[2/print.cc]
> scons: done building targets.
>
>
>
>
> One more test. Oddly enough if I change:
>
> prints.extend(env.Program(
> '{0}/print'.format(num),
> printcc
> ))
>
> To:
>
> prints.extend(env.Program(
> '{0}/print{0}'.format(num), # <-- change here, added `num` to
> name, not only path
> printcc
> ))
>
> It starts working as expected (rebuilding when I switch use_task):
>
> $ scons use_task=0
> scons: Reading SConscript files ...
> scons: done reading SConscript files.
> scons: Building targets ...
> g++ -o 1/print1 1/print.o
> g++ -o 2/print2 2/print.o
> 1/print1 -o 2/print.os -c -fPIC 2/print.cc
> Printing 1
> scons: done building targets.
>
> $ scons use_task=0 # rerun same
> scons: Reading SConscript files ...
> scons: done reading SConscript files.
> scons: Building targets ...
> scons: `1/print1' is up to date.
> scons: `2/print2' is up to date.
> scons: `2/print.os' is up to date.
> scons: done building targets.
>
> $ scons use_task=1 # switched to new
> scons: Reading SConscript files ...
> scons: done reading SConscript files.
> scons: Building targets ...
> scons: `1/print1' is up to date.
> scons: `2/print2' is up to date.
> 2/print2 -o 2/print.os -c -fPIC 2/print.cc # <-- builds as expected
> Printing 2
> scons: done building targets.
>
> $ scons use_task=1
> scons: Reading SConscript files ...
> scons: done reading SConscript files.
> scons: Building targets ...
> scons: `1/print1' is up to date.
> scons: `2/print2' is up to date
> scons: `2/print.os' is up to date.
> scons: done building targets.
>
> Even though --tree=prune looks almost exactly the same!
> The only difference are:
> - +-1/print vs +-1/print1
> - +-2/print vs +-2/print2
>
> $ scons use_task=1 --tree=prune
> scons: Reading SConscript files ...
> scons: done reading SConscript files.
> scons: Building targets ...
> scons: `1/print1' is up to date.
> +-1/print1
> +-1/print.o
> | +-1/print.cc
> | | +-#include <iostream>
> #include <fstream>
> int main(int argc, char **argv)
> {
> std::cout << "Printing " << 1 << std::endl;
> std::ofstream f(argv[2]);
> f << 1 << "\n";
> return 0;
> }
>
> | +-/usr/bin/g++
> +-/usr/bin/g++
> scons: `2/print2' is up to date.
> +-2/print2
> +-2/print.o
> | +-2/print.cc
> | | +-#include <iostream>
> #include <fstream>
> int main(int argc, char **argv)
> {
> std::cout << "Printing " << 2 << std::endl;
> std::ofstream f(argv[2]);
> f << 2 << "\n";
> return 0;
> }
>
> | +-/usr/bin/g++
> +-/usr/bin/g++
> scons: `2/print.os' is up to date.
> +-2/print.os
> +-[2/print.cc]
> scons: done building targets.
>
> But dependencies of 2/print.os are the same. Yet it rebuilds now if I
> change `use_task`.
> It looks like when given an FS.Node SCons takes into account only
> node.name instead of node.path when calculating signature.
>
>
> On 6 May 2016 at 19:37, Bill Deegan <bill at baddogconsulting.com> wrote:
>
>>
>>
>> On Fri, May 6, 2016 at 1:09 PM, Krzysztof Trzciński <
>> christopher.trzcinski at gmail.com> wrote:
>>
>>> New SConstruct:
>>>
>>> env = Environment(tools=['default', 'textfile'])
>>>
>>> prints = []
>>> for num in (1,2):
>>> printcc = env.Textfile(
>>> '{0}/print.cc'.format(num),
>>> [(
>>> '#include <iostream>\n'
>>> '#include <fstream>\n'
>>> 'int main(int argc, char **argv)\n'
>>> '{{\n'
>>> ' std::cout << "Printing " << {0} << std::endl;\n'
>>> ' std::ofstream f(argv[2]);\n'
>>> ' f << {0} << "\\n";\n'
>>> ' return 0;\n'
>>> '}}\n'
>>> ).format(num),],
>>> )
>>>
>>>
>>> prints.extend(env.Program(
>>> '{0}/print'.format(num),
>>> printcc
>>> ))
>>>
>>> env['SHCXX'] = prints[int(ARGUMENTS['use_task'])]
>>>
>>> result = env.SharedObject(printcc)
>>>
>>> Default(prints+result)
>>>
>>> Results:
>>>
>>> $ scons use_task=0
>>> scons: Reading SConscript files ...
>>> 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 -o 2/print.os -c -fPIC 2/print.cc
>>> Printing 1
>>> scons: done building targets.
>>>
>>> $ cat 2/print.os
>>> 1
>>>
>>> # Build with different compiler
>>>
>>> $ scons use_task=1
>>> scons: Reading SConscript files ...
>>> scons: done reading SConscript files.
>>> scons: Building targets ...
>>> scons: `1/print' is up to date.
>>> scons: `2/print' is up to date.
>>> scons: `2/print.os' is up to date.
>>> scons: done building targets.
>>>
>>> $ cat 2/print.os
>>> 1
>>>
>>> # Did not refresh!
>>>
>>> # Just to double check from clean:
>>>
>>> $ rm 2/print.os
>>>
>>> $ scons use_task=1
>>> scons: Reading SConscript files ...
>>> scons: done reading SConscript files.
>>> scons: Building targets ...
>>> scons: `1/print' is up to date.
>>> scons: `2/print' is up to date.
>>> 2/print -o 2/print.os -c -fPIC 2/print.cc
>>> Printing 2
>>> scons: done building targets.
>>>
>>> $ cat 2/print.os
>>> 2
>>>
>>>
>>> I don't think I should be putting compiler as "source" in `SharedObject`.
>>>
>>
>> You don't have to, it's automatically added.
>> Try running --tree=prune.
>>
>>
>>>
>>> Note that all Textfile/Program builders do here is make this self
>>> contained.
>>> The actual issues is with last three lines.
>>>
>>> In my case it was just that "prints" was populated using operating
>>> system provided paths/binaries to compilers.
>>>
>>> So I take this is a bug and it needs fixing? (if someone could point me
>>> in right direction I could try that, but I am not quite sure where
>>> substitions take place and why $SHXCC would behave differently to
>>> $SHCXX.path in a command).
>>>
>>
>> Don't file a bug yet. Let me dig into this a little bit and get back to
>> you.
>> May take a couple days.
>>
>> -Bill
>>
>> _______________________________________________
>> 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/20160627/32d1a290/attachment-0001.html>
More information about the Scons-dev
mailing list