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

Bill Deegan bill at baddogconsulting.com
Wed Aug 12 22:22:27 EDT 2020


So your use model is not strictly supported.
You have directories with a bunch of SConstructs in them and
SConsignFile(None) so it dumps a file in every source dir.
All files stored in such are relative to the invocation directory.
In essence you have a number of independent build systems which happen to
call each other thus yielding file paths which are different when you
invoke from different dirs and thus the rebuilds.

There's actually no reason to do this if your only goal is to be able to
launch the build from any source directory.
Is that your goal?
Or something else?
Please explain.

Thanks,
Bill

Or are you trying something else?

On Wed, Aug 12, 2020 at 5:43 PM Bill Deegan <bill at baddogconsulting.com>
wrote:

> 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>
> 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> on behalf of trevor
>> fitzsimmons <t_fitzs at hotmail.com>
>> *Sent:* Wednesday, July 29, 2020 11:52 AM
>> *To:* scons-users at scons.org <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
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20200812/b1b9f85d/attachment.html>


More information about the Scons-users mailing list