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

[William Blevins]

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> 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
> 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/cb171fd2/attachment-0001.html>