[Scons-users] Scons Implicity Dependency not found issue

[Hua Yanghao]

Now I am surprised and confused that my above usw_board_path(fn) is
completely redundant ... as I forgot to update one of the SConscript
file and realize everything still works as expected and no broken
dependencies, and with --tree=all I see that between variant_dir &
original_dir scons just automatically picked up the right dependencies
... I am having difficulties to understand this, for example, what if
I have a file in the original source and on-the-fly created a
different file of the same name in the variant_dir path ... which one
scons will be picking up ... or will there be a error saying they are
the same file?!
On Fri, Oct 26, 2018 at 2:59 PM Hua Yanghao <huayanghao at gmail.com> wrote:
>
> On Fri, Oct 26, 2018 at 9:45 AM Hua Yanghao <huayanghao at gmail.com> wrote:
> >
> > On Thu, Oct 25, 2018 at 10:08 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
> >
> > Thanks Jason. I am seriously considering doing so now ...
>
> In my build system, I made a clear decision that all compiled files
> goes to the variant_dir, such that the source folders are intact. This
> enabled a uniform way to specifying external dependencies where either
> a scons scanner is missing. Now If I use duplicate=0, then I need two
> different system to specify this kind of dependency, one for the files
> that is in the original source folders, and one for the files that is
> created on the fly in the variant_dir ... this breaks user APIs ...
> but I do see the build speed up quite a bit.
>
> So finally I come up with a new user-visible API that in SConscript
> for users: usw_board_path(fn): return
> os.path.join("#"+env["USW_BUILD_PATH"], env["USW_BUILD_FOLDER"], fn),
> I can see sometimes, especially with variant_dir, scons tries to be
> really smart (maybe a bit too much) that it tries to translate every
> single path it sees if without the leading #.
>
> I think I will settle with this one, looks like we really should use
> duplicate with great caution.
>
> Thanks Jason for sharing the experience of duplicate=1.
>
> BR, Yanghao