Re: SCons missing dependencies (not rebuilding files when they need to be)

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-cJFiu+DHMVC5azolltMz9laTQe2KTcn/@public.gmane.org> wrote:

>
>
> On Fri, May 6, 2016 at 1:09 PM, Krzysztof Trzciński <
> [email protected]> 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
> [email protected]
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>

_______________________________________________
Scons-dev mailing list
[email protected]
https://pairlist2.pair.net/mailman/listinfo/scons-dev