[Scons-users] Recursive directories, and the ignoring of filenames.

[Alistair Buxton]

On 3 August 2018 at 19:26, Bill Deegan <bill at baddogconsulting.com> wrote:
>
>
> On Fri, Aug 3, 2018 at 11:25 AM, Alistair Buxton <a.j.buxton at gmail.com>
> wrote:
>>
>> On 3 August 2018 at 19:20, Bill Deegan <bill at baddogconsulting.com> wrote:
>>
>> >
>> > Here's what you said in your initial email
>> > "All files under /some/path will be inserted into the image. Therefore,
>> > if any file or subdirectory is renamed, the image needs to be rebuilt,"
>> >
>> > So in the case above, rebuilding is correct?
>>
>> Yes, it is the correct behaviour, but it happens for the wrong reason.
>> It happens as a result of the action string changing, NOT because the
>> sources changed, and as I wrote:
>
>
> Why is this the wrong reason?

Because the purpose of the example was to demonstrate that scons does
not reliably rebuild when the sources list changes. The fact that it
rebuilds if the action string changes is completely irrelevant, and
not helpful in the case where the tool takes a single directory as the
only argument.

>> On 3 August 2018 at 00:53, Alistair Buxton <a.j.buxton at gmail.com> wrote:
>>
>> > However, this is not so easy with the image builder case as it takes a
>> > directory path as the only argument.
>>
>> In other words, the action string will not change when you have a tool
>> which takes a single directory path as the only argument, and as a
>> result, the build will not be re-run.
>
>
> This is typically where a scanner would come into play.

Since a scanner returns a list of dependencies, and the problem is due
to the way scons internally processes dependency lists, this will not
solve the problem, and will in fact have identical behaviour, unless
you write the scanner to return a Value containing a recursive
checksum similar to the one I presented in the first email - which btw
is the only reliable recursive dependency code presented so far in
this thread, assuming I typed it out correctly :)

-- 
Alistair Buxton
a.j.buxton at gmail.com