[Scons-users] SConsignFile(None) + Decider('MD5-timestamp')

[trevor fitzsimmons]

When not using SConsignFile(None), regardless of Decider, building from directories doesn't have the "infinite loop" of rebuilding like I'm trying to address, but building from each directory will cause a full rebuild once.

So, in the test case, building from test would cause a full build, and then trying to build from test/src would also cause a full rebuild.  After that, scons will detect everything as up-to-date, regardless of where you build from.

In practice, I don't really keep building alternately from 2 different directories.  What I'm really after is targets being correctly identified as up-to-date, regardless of the level at which the build is executed.

________________________________
From: Scons-users <scons-users-bounces at scons.org> on behalf of Bill Deegan <bill at baddogconsulting.com>
Sent: Wednesday, August 12, 2020 8:43 PM
To: SCons users mailing list <scons-users at scons.org>
Subject: Re: [Scons-users] SConsignFile(None) + Decider('MD5-timestamp')

If you don't use SConsignFile(None), then is this still an issue?
Any reason you want a per directory sconsignfile?

On Wed, Aug 12, 2020 at 6:47 AM trevor fitzsimmons <t_fitzs at hotmail.com<mailto:t_fitzs at hotmail.com>> wrote:
I've dug more into this issue, and have attached a proposed patch against scons-4.0.1.

The general idea is to pass the parent node to _build_dependency_map, to then correlate "children" to signatures the same way Node/__init__.py changed() does, rather than using bsources/etc.  This fixes the pathing issues, and should perform the same when building from the same directory repeatedly.

Can anyone verify the bug, or provide feedback on the proposed patch?

Should I open a bug report instead?

Thanks,
Trevor

________________________________
From: Scons-users <scons-users-bounces at scons.org<mailto:scons-users-bounces at scons.org>> on behalf of trevor fitzsimmons <t_fitzs at hotmail.com<mailto:t_fitzs at hotmail.com>>
Sent: Wednesday, July 29, 2020 11:52 AM
To: scons-users at scons.org<mailto:scons-users at scons.org> <scons-users at scons.org<mailto:scons-users at scons.org>>
Subject: [Scons-users] SConsignFile(None) + Decider('MD5-timestamp')

Since scons-3.0.2 (through the current scons-4.0.1), using SConsignFile(None) in conjunction with Decider('MD5-timestamp') causes scons to rebuild targets when invoked from different directories in the source code hierarchy.

Attached is a simple example to illustrate the issue.  Building from test/src will cause an initial build as expecting.  Building again from test/src will do nothing, as expected, and report everything is up-to-date.  However, if you build from test, everything in test/src will be rebuilt, even though it is already up-to-date.  Building again from test will do nothing, as expected, and report everything is up-to-date.  Building from test/src will then cause another full rebuild, even though everything is up-to-date, and the cycle continues.

This has something to do with the dependency_map which was added in Node/FS.py in scons-3.0.2, but I do not know enough about the inner workings of scons to propose a fix.  FS.py changed_timestamp_then_content(self, target, prev_ni, node=None) calls prev_ni = self._get_previous_signatures(dependency_map).  Depending on the starting directory, self is either main.cpp or src/main.cpp, while the key in dependency_map is the other.

In our full code-base, it's quite usual to build in a subdirectory while changing code, to avoid waiting on a full build, so the current work-around is to not use Decider('MD5-timestamp').  It would be ideal to have a patch that could eventually be applied to scons, to fix the issue in a future version.

Thanks
_______________________________________________
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/20200813/f9b73a6c/attachment.html>