This issue was originally created at: 2013-05-14 09:21:18.
This issue was reported by: unclezeiv.

unclezeiv said at 2013-05-14 09:21:18

Simple case:

env = Environment()
env.VariantDir('build/variant1/', 'src', duplicate=0)
env.Depends(['src/test.cc'], ['src/input.strings'])
env.Program('bin/Linux64/test', ['build/variant1/test.cc'])

This is the resulting --tree=all dependency tree:

+-.
  +-SConstruct
  +-bin
  | +-bin/Linux64
  |   +-bin/Linux64/test
  |     +-build/variant1/test.o
  |     | +-src/test.cc          <------------ NO DEPENDENCY
  |     | +-/usr/bin/g++
  |     +-/usr/bin/g++
  +-build
  | +-build/variant1
  |   +-src/test.cc
  |   +-build/variant1/test.o
  |     +-src/test.cc            <------------ NO DEPENDENCY
  |     +-/usr/bin/g++
  +-src
    +-src/input.strings
    +-src/test.cc                <------------ CORRECT DEPENDENCY
      +-src/input.strings

Notice how src/test.cc appears several times, but only once the dependency on input.strings is correctly identified. When build/variant1/test.o correctly resolves to src/test.cc via VariantDir, it doesn't seem to remember the dependency - and, as a matter of fact, changing input.strings does indeed NOT trigger a recompilation :(

Contrast this with the tree that I get when NOT using VariantDir:

+-.
  +-SConstruct
  +-bin
  | +-bin/Linux64
  |   +-bin/Linux64/test
  |     +-src/test.o
  |     | +-src/test.cc
  |     | | +-src/input.strings  <-------------- CORRECT DEPENDENCY
  |     | +-/usr/bin/g++
  |     +-/usr/bin/g++
  +-src
    +-src/input.strings
    +-src/test.cc
    | +-src/input.strings        <-------------- CORRECT DEPENDENCY
    +-src/test.o
      +-src/test.cc
      | +-src/input.strings      <-------------- CORRECT DEPENDENCY
      +-/usr/bin/g++

This does not only happen when using Depends() explicitly. Also adding a custom builder to a node seems to be lost in the process.

Any help or workaround would be appreciated. Thank you.

(I'm testing this under Python 2.6 and Linux, but it doesn't look platform dependent).

bdbaddog said at 2013-05-14 11:41:52

If you change it to:

env.VariantDir('build/variant1/', 'src', duplicate=0)
env.Depends(['build/variant1/test.cc'], ['src/input.strings'])

Does it work?

In general, if you have a problem, you are better off first bringing it to the attention of the scons users mailing list. And then if it cannot be resolved and/or someone asks you to file it as a bug, then to proceed to do so.

unclezeiv said at 2013-05-14 16:44:03

Ok, will do, but let me just clarify that I'm not trying to make this toy example work. It took me a long time to distill the problem to what I think it's its essence. I thought the dependency tree dump was evidence enough of a misbehaviour. But I'll seek for advice on the mailing list first, thanks.

garyo said at 2013-05-15 05:23:28

This line is incorrect:

env.Depends(['src/test.cc'], ['src/input.strings'])

Saying that a source file depends on some other file doesn't cause anything to happen; source files have no builders. It's basically meaningless. Perhaps you mean to say that src/test.o (the object file) depends on src/input.strings, i.e. SCons should rebuild test.o whenever input.strings has changed?

unclezeiv said at 2013-05-15 05:43:58

Hi Gary, that's actually a good point. I should point out though that:

1. nonetheless it does indeed work in the non-VariantDir case; so at the very least there's a behaviour that is different between the two cases
2. this is a toy example. In my real case I do actually generate src/test.cc with a builder. I removed that part as I thought it was not fundamental for describing the problem. And again, even in that case, it works when not using VariantDir, it doesn't otherwise.

I poked around the Scons source and it looks like at some stage Scons is aware of src/test.cc having a builder and some dependencies, while at some later stage this info is lost. I can give you more details on this if you want, but I don't really understand the code base.

Thank you guys for your help.

Votes for this issue: 1.