[Scons-users] Scons Implicity Dependency not found issue

[Hua Yanghao]

Hi Bill,
Unfortunately not for my real build out of box.
I think I should be able to modify my build system to avoid using
duplicate, but that's actually one of the feature I love most ... e.g.
for every single build I have a exact snapshot of only those source
files (include .h files) that actually being used, and I could simply
package the build folder for a self-contained build. As all of the
build shares the same sources this way it is very clear to understand
what actually went into the build.

It is definitely not showstopper, as you just need to build it again
when it failed or simply do a clean before re-build. It is just a bit
annoying knowing that incremental build could fail when you move
around header files and having duplicate enabled.

I will also try to look into the source code as Mats did but not sure
if I can make much sense out of it quickly ...

Best Regards,
Yanghao
On Thu, Oct 25, 2018 at 6:44 PM Bill Deegan <bill at baddogconsulting.com> wrote:
>
> 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
>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users