[Scons-users] Scons Implicity Dependency not found issue

Thu Oct 25 16:08:52 EDT 2018

Hi,

I would recommend myself that you use duplicate=0 then. The point for duplicate=1 as default is that there are some tools that don't deal with files input output location and to help avoid possible issues if you have a large build and you might have modified a file while the build was going on ( given you tell SCons to make copies instead of hardlinks... ie this is the --duplicate option). There are a few issues with this however:

1) windows will make copies as SCons does not understand symlink or hard links on this platform with out some extension added to it
2) takes extra times as one has to create items
3) when it is making copies I have had issues I cannot explain yet ( ie not looked in to enough) where scons does not update the files in the variantdir correctly making bad builds. ( I think that is what you are seeing)

For large build the time save with duplicate=0 is a big deal, as well as the disk savings given the hard-soft-copy options is not working correctly

Bill -- just a guess but I think the issue when copy is being used is that SCons nodes understand the variant and srcnode exists, but has no check, or depends logic to say variant version depends on the srcnode version so there are cases in which a depends on a variant node does mean that the srcnode "copy" update is not seen. So for example the scanner does gets a file and tests that it exists, but since the header does not have any builder the logic to understand that the it should update based on the value of srcnode() version is skipped.

-Jason
________________________________
From: Hua Yanghao <huayanghao at gmail.com>
Sent: Thursday, October 25, 2018 1:51 PM
To: dragon512 at live.com
Cc: SCons users mailing list
Subject: Re: [Scons-users] 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 <dragon512 at live.com> 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 <scons-users-bounces at scons.org> on behalf of Hua Yanghao <huayanghao at gmail.com>
> 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 <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://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist4.pair.net%2Fmailman%2Flistinfo%2Fscons-users&data=02%7C01%7C%7Cde06ffb3a830484d389608d63aaae420%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636760902970322438&sdata=nuF8C5CrX6Qdg6IGm12Bo6uEjirDPzLCBtrO8idvGJw%3D&reserved=0
> >
> > _______________________________________________
> > Scons-users mailing list
> > Scons-users at scons.org
> > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist4.pair.net%2Fmailman%2Flistinfo%2Fscons-users&data=02%7C01%7C%7Cde06ffb3a830484d389608d63aaae420%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636760902970322438&sdata=nuF8C5CrX6Qdg6IGm12Bo6uEjirDPzLCBtrO8idvGJw%3D&reserved=0
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist4.pair.net%2Fmailman%2Flistinfo%2Fscons-users&data=02%7C01%7C%7Cde06ffb3a830484d389608d63aaae420%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636760902970322438&sdata=nuF8C5CrX6Qdg6IGm12Bo6uEjirDPzLCBtrO8idvGJw%3D&reserved=0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20181025/b1cd7294/attachment-0001.html>