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

[Kenny, Jason L]

I would agree,

I only pointing this out and an issue that might come up next once the “get a link that should link to link” is fixed. We then get the common link that should not need to link. I am sure people have seen this, it more of an issue when you have large builds with lots of linking in it.

Jason


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

Jason,

I was only trying to cover issue #2.  I assume incremental linking support is a rather large effort.

V/R,
William

On Thu, Jun 11, 2015 at 10:39 AM, Kenny, Jason L <jason.l.kenny at intel.com<mailto:jason.l.kenny at intel.com>> wrote:
I should note form an incremental liking point of view the main failure I have seen with this is that an object file we rebuilt, but it results in the same exact file. SCons will relink/rebuild the binary because of some logic that just assumes that If the child changes the parent has to as well. But it a common case people add comments or something to have results in the same output. This is where SCons could skip the rebuilt in many cases as this results in the same output. This is not 100% true as some builder output might have timestamp info, etc added to the output based on when it ran as well. The current logic covers this case, it would be nice if we could do something to get the first case right as well as when you have 100 so files and the one change on the bottom can cause 100 relinks that are not needed when the rebuilt .o results in the same output.

This is a bit the reverse of the current issue.

Jason

From: Scons-users [mailto:scons-users-bounces at scons.org<mailto:scons-users-bounces at scons.org>] On Behalf Of William Blevins
Sent: Thursday, June 11, 2015 9:33 AM

To: SCons users mailing list
Subject: Re: [Scons-users] Making SCons deal more robustly with incremental linking

I also thought that SCons would rebuild.  It didn't.  I made a patch that should fix the issue if we decide that it should be fixed.

V/R,
William

On Thu, Jun 11, 2015 at 10:31 AM, Kenny, Jason L <jason.l.kenny at intel.com<mailto:jason.l.kenny at intel.com>> wrote:
I think got that, I thought SCons would have seen this as inconstant and rebuilt.

Jason

From: Scons-users [mailto:scons-users-bounces at scons.org<mailto:scons-users-bounces at scons.org>] On Behalf Of William Blevins
Sent: Thursday, June 11, 2015 9:27 AM
To: SCons users mailing list

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

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<mailto: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<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<mailto: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<mailto:Scons-users at scons.org>
https://pairlist4.pair.net/mailman/listinfo/scons-users
_______________________________________________
Scons-users mailing list
Scons-users at scons.org<mailto:Scons-users at scons.org>
https://pairlist4.pair.net/mailman/listinfo/scons-users


_______________________________________________
Scons-users mailing list
Scons-users at scons.org<mailto:Scons-users at scons.org>
https://pairlist4.pair.net/mailman/listinfo/scons-users


_______________________________________________
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/98340b4d/attachment-0001.html>