Re: Scons Implicity Dependency not found issue

Hi Jason,
I am pretty sure (though not yet tried) I can convert and use
duplicate=0, this is independent of the stripping of the variant_dir
issue we discussed in the other thread.
The only reason I am using duplicate=1 is: 1. it is the default (means
scons recommended?) 2. I really like to have a clear copy of those
files that has been used.

I do not have any use case where the tool cannot accept a $SOURCE
value that points to the original file path.

Best Regards,
Yanghao
On Thu, Oct 25, 2018 at 8:37 PM Jason Kenny <[email protected]> wrote:
>
> I have had various issue with duplicate=1. I myself default use duplicate=0 myself. In both cases I believe the source directory and the variant directory are added to the path. If i understand right you have the case in which you need the builder to run in the variant dir and having duplicate=1 means you should have copies or link to the source file in the variant which will make the tool work.
>
> are you having a case in which your tool cannot accept a $SOURCE value that would point to the file in some place that is not the current directory?
>
> Jason
> ________________________________
> From: Scons-users <[email protected]> on behalf of Hua Yanghao <[email protected]>
> Sent: Thursday, October 25, 2018 1:27 PM
> To: SCons users mailing list
> Subject: Re: [Scons-users] Scons Implicity Dependency not found issue
>
> 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 <[email protected]> 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 <[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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist4.pair.net%2Fmailman%2Flistinfo%2Fscons-users&amp;data=02%7C01%7C%7C96025d888bb841a3025708d63aa78a08%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636760888575981043&amp;sdata=%2B6GJG3cTWwgyrK%2BWsvpurWG4OiItHiffkOlHoY7eoxc%3D&amp;reserved=0
> >
> > _______________________________________________
> > Scons-users mailing list
> > [email protected]
> > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist4.pair.net%2Fmailman%2Flistinfo%2Fscons-users&amp;data=02%7C01%7C%7C96025d888bb841a3025708d63aa78a08%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636760888575981043&amp;sdata=%2B6GJG3cTWwgyrK%2BWsvpurWG4OiItHiffkOlHoY7eoxc%3D&amp;reserved=0
> _______________________________________________
> Scons-users mailing list
> [email protected]
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist4.pair.net%2Fmailman%2Flistinfo%2Fscons-users&amp;data=02%7C01%7C%7C96025d888bb841a3025708d63aa78a08%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636760888575981043&amp;sdata=%2B6GJG3cTWwgyrK%2BWsvpurWG4OiItHiffkOlHoY7eoxc%3D&amp;reserved=0
_______________________________________________
Scons-users mailing list
[email protected]
https://pairlist4.pair.net/mailman/listinfo/scons-users