[Scons-users] Scons Implicity Dependency not found issue

[Mats Wichmann]

On 10/25/2018 02:17 AM, Hua Yanghao wrote:
> Hi Mats,
> This is exactly what happened in my build system, where people move
> header files around and then do a incremental compilation and it
> failed.
> Shouldn't scons always starts by checking if all the mirroring of
> files in the build folder is actually up-to-date to the source
> folders?
> Refactoring and moving header files around is a very common operation
> during project development, and the fact that the second pass builds
> OK tells somehow scons was actually able to get this right, just not
> on the first shot.

If you want to see what scons "remembers", you can do this in your test
directory:

sconsign .sconsign.dblite

When I do that I see build/a/test.o has depends on its sources in
build/a, and I assume the error message means that scons concludes those
are not "real" files since they're under the variant dir.

Flipping your variant_dir calls to non-copying (add duplicate=0 to the
SConscript call), the test works for me, presumably because now there is
no dangling "reference" to a test.h that no longer exists.  Just trying
to piece it together. With all respect to the core developers, I have
found the logic behind both forms of variant_dir (copying and
non-copying) to be a bit dodgy, I can't get either one to work quite as
my mental model would have them behave.  Perhaps that's just faulty
mental models...


The interesting part here is for the case that's going to fail, we have:

=== build/a:
...
test.o: 745af4c9af338033022943cbc558f5e4 1540423561 1376
        build/a/test.c: 4b4a4cc225f4757288dc5abbbc7cb14b 1540475790 109
        build/a/include/test.h: b972e789a649e1bc6875ff6f40531f7e
1540475790 14

Without changing anything else, I change SConstruct to use non-copying
mode and rerun scons and it works, and the sconsign file now contains:

=== build/a:
...
test.o: 745af4c9af338033022943cbc558f5e4 1540480755 1376
        a/test.c: 29f8028f861e5483353fd5d15dee8adb 1540480544 108
        b/include/test.h: b972e789a649e1bc6875ff6f40531f7e 1540480544 14

so now the dependencies point to the "real" sources, not the
shadowed-by-copying ones....

Hmmm.