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

[William Blevins]

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>
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] *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>
> 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
>
>
>
> _______________________________________________
> 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/3be69507/attachment-0001.html>