[Scons-users] Scons Implicity Dependency not found issue
Hua Yanghao
huayanghao at gmail.com
Fri Oct 26 08:59:27 EDT 2018
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
More information about the Scons-users
mailing list