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

[Kenny, Jason L]

I think on case in which this happens a lot is when SCons has to call a makefile in which it may not know about everything. In the case of linking we get a odd behavior when people start to sign binaries or add manifests.

Jason

From: Scons-users [mailto:scons-users-bounces at scons.org] On Behalf Of William Blevins
Sent: Thursday, June 11, 2015 9:08 AM
To: Dirk Bächle; SCons users mailing list
Subject: Re: [Scons-users] Making SCons deal more robustly with incremental linking

Dirk,

Although I agree that this shouldn't be an issue in normal cases, but I don't think it will hurt anything to check if leaf nodes have been corrupted.

V/R,
William

On Thu, Jun 11, 2015 at 9:31 AM, Dirk Bächle <tshortik at gmx.de<mailto:tshortik at gmx.de>> wrote:
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<mailto: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/a40f6b51/attachment-0001.html>