[Scons-users] Scons Implicity Dependency not found issue
Bill Deegan
bill at baddogconsulting.com
Thu Oct 25 12:43:46 EDT 2018
Yes. It should work as is with SCons.
Not sure exactly why it's not but looking into it.
It looks like using duplicate=0 should remove this issue for the time being.
Is that something you're able to do with your build?
=Bill
On Thu, Oct 25, 2018 at 8:29 AM Mats Wichmann <mats at wichmann.us> wrote:
> 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.
>
>
> _______________________________________________
> 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/20181025/e5b6f1df/attachment.html>
More information about the Scons-users
mailing list