[Scons-users] What affects rebuilding?

Douwe Gelling douwegelling at gmail.com
Tue Jun 30 11:04:22 EDT 2015


I don't know specifics of scons, but it seems to me this isn't the issue.
I've applied the patch to be certain, and it doesn't work in any case.
It almost looks like the wrong files are compared when using variantdir, or
perhaps some fields of the File object are being compared
that shouldn't be. I'll have a look at the changed_since_last_build
function, see what fields are compared.

On 30 June 2015 at 16:37, William Blevins <wblevins001 at gmail.com> wrote:

> I think this is the issue you are describing.
>
> http://scons.tigris.org/issues/show_bug.cgi?id=2980
>
> There is part of a patch attached.  I looked at it at some point, but
> there were still tests failing.
>
> V/R,
> William
>
> On Tue, Jun 30, 2015 at 10:23 AM, Douwe Gelling <douwegelling at gmail.com>
> wrote:
>
>> I have a problem where scons rebuilds files when I change targets on the
>> commandline.
>> I make use of the COMMAND_LINE_TARGETS list to optionally use some other
>> sconsfiles,
>> and also use variant directories to set the object output directories. It
>> seems somehow this
>> may all be interacting with each other.
>>
>> Specifically, I get the following type of behaviour:
>>
>> 1. I build my program using the default target (scons -jN ...)
>>
>> 2. I build some extra program by setting a new target. It depends on some
>> files that were compiled before,
>>     but decides to rebuild it. Using --explain, I get the following type
>> of message:
>>
>> rebuilding 'a/b/c/d.o' because
>>    a/b/c/d.cpp is no longer a dependency
>>    a/b/c/d.cpp is a new dependency
>>
>> 3. I build my default program again, scons rebuilds everything yet again,
>> giving the same message as in 2.
>>
>> I've changes the scons source a bit to show more information in the
>> explain function, and it turns out that
>> in both steps 2 and 3, the file that is no longer a dependency is the
>> original cpp file, and the file that is a
>> new dependency is the file located in the variant directory (say,
>> a/b/c/obj/linux/x86_64/d.cpp).
>>   This happens even though in the call to VariantDir, duplicate is set to
>> 0. If I set it to 1 instead, the message
>> scons gives me is that it's rebuilding 'because the contents of the build
>> action changed'
>>
>>
>> On 30 June 2015 at 15:31, William Blevins <wblevins001 at gmail.com> wrote:
>>
>>> See the Decider section of the man page for how scons determines if a
>>> source has changed.
>>>
>>> SCons also checks for changes to the overall build command as generated
>>> by the executor.
>>>
>>> What is your specific question?
>>>
>>> V/R,
>>> William
>>> On Jun 30, 2015 5:28 AM, "Douwe Gelling" <douwegelling at gmail.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I'm wondering which things scons tracks when deciding whether or not to
>>>> rebuild a file, apart
>>>> from the file itself. I know changing commandline variables forces a
>>>> rebuild, but are there other
>>>> things that do the same? For example, does scons look for changes in
>>>> the environment for a particular file? Or something else?
>>>>
>>>> thanks
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>
> _______________________________________________
> 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/20150630/70285592/attachment-0001.html>


More information about the Scons-users mailing list