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

[Bill Deegan]

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?
>
> On 5 May 2016 at 21:41, <scons-dev-request at scons.org> wrote:
> Welcome to the Scons-dev at scons.org mailing list!
>
> To post to this list, send your message to:
>
>   scons-dev at scons.org
>
> General information about the mailing list is at:
>
>   https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
> If you ever want to unsubscribe or change your options (eg, switch to
> or from digest mode, change your password, etc.), visit your
> subscription page at:
>
>
> https://pairlist2.pair.net/mailman/options/scons-dev/christopher.trzcinski%2Bscons%40gmail.com
>
>
> You can also make such adjustments via email by sending a message to:
>
>   Scons-dev-request at scons.org
>
> with the word `help' in the subject or body (don't include the
> quotes), and you will get back a message with instructions.
>
> You must know your password to change your options (including changing
> the password, itself) or to unsubscribe without confirmation.  It is:
>
>   MJwKL3hoS2sc
>
> Normally, Mailman will remind you of your scons.org mailing list
> passwords once every month, although you can disable this if you
> prefer.  This reminder will also include instructions on how to
> unsubscribe or change your account options.  There is also a button on
> your options page that will email your current password to you.
>
>
> _______________________________________________
> 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://pairlist4.pair.net/pipermail/scons-users/attachments/20160506/46f46ac7/attachment.html>