Re: Scons Implicity Dependency not found issue
Bill Deegan <[email protected]>
| Newsgroups | gmane.comp.programming.tools.scons.user |
|---|---|
| Message-ID | <CAEyG4CHGxYFOth8-N7Pi91ap7+vxTZySpuCe8AXu8y4dO3XmAA@mail.gmail.com> |
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 <[email protected]> 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 > [email protected] > https://pairlist4.pair.net/mailman/listinfo/scons-users > _______________________________________________ Scons-users mailing list [email protected] https://pairlist4.pair.net/mailman/listinfo/scons-users