[Scons-users] Question on Depends behavior vs. documentation (src_builders)

[Brennen, Jack]

I'm confused here by the behavior of the example in Section 6.5 of the SCons User Guide 2.1.0.  It deviates from my observed behavior.  I'm seeing this:


$ cat SConstruct
hello = Program('hello.c')
Depends(hello, 'other_file')
$ scons -Q hello
gcc -o hello.o -c hello.c
gcc -o hello hello.o
$ scons -Q hello
scons: `hello' is up to date.
$ echo '#' >> other_file
$ scons -Q hello
gcc -o hello hello.o


In particular, it seems to only re-run the link step if "other_file" is modified; it doesn't re-run the compile step.


This isn't particularly surprising to me, as I understand that there's an intermediate node hello.o between hello.c and hello, and I applied the dependency to the final program hello, not to hello.o.


However, it conflicts directly with the example in Section 6.5 of the user guide, which shows that both build steps are re-run after modifying "other_file".



Note that I'm not just complaining about the documentation not matching reality.  This comes about because I'm trying to make a builder of the "Program" style -- a builder that has src_builders that create intermediate nodes -- but I want something like Depends(target, 'other_file') to re-execute the entire builder including the src_builders.  I tried basing it on Program(), but found that Program() doesn't behave as advertised.  If somebody could tell me the magic incantation to get a builder to re-execute the src_builders every time a dependency changes, that would help me out a lot.


All I've been able to come up with so far would be to have the builder wrap its _execute() method with one that saves the source Node list before calling the real _execute() method, and then add those sources back in to each Node returned by _execute() using add_dependency(), something like this pseudo-code:


   def _execute(self, env, target, source):
      ret = self.original_execute(env, target, source)
      for node in ret:
         node.add_dependency(node,source):
      return ret

I'm not too thrilled with doing something like that, though -- it looks like a total hack, and also seems like something that should be able to work in a much easier way.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20160930/1f440a44/attachment.html>