[Scons-users] Making SCons deal more robustly with incremental linking

William Blevins wblevins001 at gmail.com
Thu Jun 11 10:26:53 EDT 2015


Jason,

In his example, he compiled outside the SCons builder, then reverted the
modified object and library files to their previous state leaving the leaf
node (E.G. an compiled executable objects -> libraries -> exe) with a
different md5sum; thus, the ninfo.csig for the node as listed in the scons
database is different than the csig of the node on the filesystem.

The patch I supplied previously would allow SCons to check if these leaf
nodes are modified outside the SCons context.

V/R,
William

On Thu, Jun 11, 2015 at 10:13 AM, Kenny, Jason L <jason.l.kenny at intel.com>
wrote:

> I am confused on this .
>
> A leaf node did not change. How was this done?  Normally this is done by
> creating a hashsum and comparing that it is the same with the one stored.
> How is this not recreated and still correct? Just because the children did
> not change does not mean the given file did not change.
>
> Jason
>
> -----Original Message-----
> From: Scons-users [mailto:scons-users-bounces at scons.org] On Behalf Of
> Dirk Bächle
> Sent: Thursday, June 11, 2015 8:32 AM
> To: scons-users at scons.org
> Subject: Re: [Scons-users] Making SCons deal more robustly with
> incremental linking
>
> Hi,
>
> On 10.06.2015 07:52, William Blevins wrote:
> > Looks like the issue exists in class Node method changed().
> >
> > The function does not evaluate whether its signature has changed. At a
> > glance, I'm not sure how to perform the check, but it should be simple
> since the md5sum or other metadata should already be stored somewhere...
> >
>
> it's a rather simple check indeed, which is omitted for improved speed
> performance. It's assumed that SCons has full control over the build and
> that all dependencies are correctly tracked...so when no children changed
> why rebuilding the hashsum for the target?
> It *must* be the same as before if it exists. ;)
>
> The basic problems here are the cyclic dependency based on incremental
> linking (this is exactly why Gold adds a build ID to each target, I guess)
> and trying to allow "external linking" by manually calling command lines
> (?). SCons can't account for what people are doing outside of its scope...I
> can only imagine a pseudo-Builder to work, which would have to relink files
> automatically until all symbols are resolved (similar to the LaTeX PDF
> Builder).
>
> Best regards,
>
> Dirk
>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
> _______________________________________________
> 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/20150611/bf8f2fc5/attachment.html>


More information about the Scons-users mailing list