[Scons-users] Bug in up_to_date for directory targets

[Manish Vachharajani]

I already have, below is the output for my simple example - like I said, it
considers the target up to date.  This is the tree output when scons should
be re-running the builder but doesn't.  The tree is correct, target foo
depends on foo-contents.txt but it considers both foo and foo-contents.txt
up to date.  If you use the python debugger and trace the flow to the point
where it calculates the readiness of foo, you clearly see that it never
executes the .changed logic for foo-contents.txt (i.e., it never compares
the signature of foo-contents.txt to what is in the .sconsign file).  If
there were a file target, it does, but only in the context of computing
is_up_to_date for that file target, the Dir target is still broken but it
doesn't matter because the builder will rerun due to the file and update
everything.


$ scons --tree=all,status
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
scons: `foo' is up to date.
 E         = exists
  R        = exists in repository only
   b       = implicit builder
   B       = explicit builder
    S      = side effect
     P     = precious
      A    = always build
       C   = current
        N  = no clean
         H = no cache
[E B   C  ]+-foo
[E     C  ]  +-foo-contents.txt
[E     C  ]  +-/bin/mkdir
[E     C  ]  +-/bin/cp
scons: done building targets.


On Mon, Mar 20, 2017 at 2:51 PM, Bill Deegan <bill at baddogconsulting.com>
wrote:

> Manish,
>
> Take a look at the output of: scons --tree=all, that's the dependency tree
> that SCons builds in processing any build.
>
> -Bill
>
> On Mon, Mar 20, 2017 at 1:47 PM, Manish Vachharajani <
> manishv at unbounded.systems> wrote:
>
>> I believe there is a bug in how up to date is computed for file nodes and
>> directory targets.  Below is a SConstruct and run output illustrating the
>> bug.
>>
>> ##############
>> # SConstruct
>> env = Environment()
>> targets = env.Command('foo',
>>                       'foo-contents.txt',
>>                       ['mkdir foo',
>>                        'cp foo-contents.txt foo'])
>> env.Default(targets)
>>
>> ##############
>> # Shell log
>>
>> # Create the file that will be installed into foo/foo-contents.txt
>> $ echo "Hello, " >> foo-contents.txt
>> # All is well, scons runs the command builder as expected
>> $ scons
>>
>> scons: Reading SConscript files ...
>> scons: done reading SConscript files.
>> scons: Building targets ...
>> mkdir foo
>> cp foo-contents.txt foo
>> scons: done building targets.
>>
>> # All is well, the target is up to date as expected
>> $ scons
>>
>> scons: Reading SConscript files ...
>> scons: done reading SConscript files.
>> scons: Building targets ...
>> scons: `foo' is up to date.
>> scons: done building targets.
>>
>> # Uh-oh, source is updated but the target is considered up to date!
>> $ echo "World!" >> foo-contents.txt
>> $ scons
>>
>> scons: Reading SConscript files ...
>> scons: done reading SConscript files.
>> scons: Building targets ...
>> scons: `foo' is up to date.
>> scons: done building targets.
>>
>> For the bug to trigger, all targets for a builder must be directories.
>> The target directory must exist and the source file must exist and be out
>> of date due to a content update (resulting in a signature mismatch).
>>
>> I think the problem is that is_up_to_date for File nodes only checks the
>> signatures of its children, which avoids this bug as long as one of the
>> builder targets is a File and not a Directory.  However, I haven't done
>> enough analysis to be sure that this is the issue.
>>
>> A work around is to make sure that you have a file (or create a dummy
>> .built file) and include it as a target.
>>
>> This is showing up specifically for us when trying to calculate
>> dependencies for a package manager (npm) where we have no insight into the
>> contents of the resulting directory.
>>
>> Manish
>>
>> _______________________________________________
>> Scons-users mailing list
>> Scons-users at scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
>>
>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20170320/be8bc7ec/attachment.html>