[Scons-users] Scons Implicity Dependency not found issue

Thu Oct 25 19:56:07 EDT 2018

Jason,

I believe the scanner is seeing the file, and then the duplicate logic is
removing it, so when the taskmaster goes to walk it, it fails.
I haven't had a chance to verify this hypothesis.
Likely the common usage is not to explicitly list the variant dir
equivalent of the source in the CPPPATH?
-Bill

On Thu, Oct 25, 2018 at 1:09 PM Jason Kenny <dragon512 at live.com> wrote:

> 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
> _______________________________________________
> 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/fdbdda1c/attachment.html>