[Scons-users] [Scons-dev] SCons missing dependencies (not rebuilding files when they need to be)

[Bill Deegan]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20160506/208f414d/attachment.html>