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

Bill Deegan <bill-cJFiu+DHMVC5azolltMz9laTQe2KTcn/@public.gmane.org>
Newsgroups gmane.comp.programming.tools.scons.devel
Message-ID <CAEyG4CE6rb-F1SeMfy8GVkuJAU-UJbDHAVTG94mwU52=2=HpDw__38556.8367936232$1462551487$gmane$org@mail.gmail.com>
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 <
[email protected]> 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-cJFiu+DHMVC5azolltMz9laTQe2KTcn/@public.gmane.org> 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 <
>> [email protected]> 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-cJFiu+DHMVC5azolltMz9laTQe2KTcn/@public.gmane.org> wrote:
>>>
>>>>
>>>>
>>>> On Fri, May 6, 2016 at 8:36 AM, Bill Deegan <bill-cJFiu+DHMVC5azolltMz9laTQe2KTcn/@public.gmane.org>
>>>> 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 <
>>>>> [email protected]> 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
>>>> [email protected]
>>>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
> _______________________________________________
> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.