[Scons-dev] Why are Builders excluded from env.Clone()?
Jonathon Reinhart
jonathon.reinhart at gmail.com
Fri Dec 9 13:10:41 EST 2016
Hi Dirk,
Thanks for pointing out that issue to me; I hadn't found it in my searches.
On Fri, Dec 9, 2016 at 12:31 PM, Dirk Bächle <tshortik at gmx.de> wrote:
>> BUILDERS is explicitly excluded in the semi_deepcopy_dict() call.
>>
>> My questions:
>> - Why are Builders explicitly excluded from the env.Clone()?
>
>
> Because it's possible that during the deep-copy, the original is altered too
> (see comment in BuilderDict::__semi_deepcopy__).
After reading the comment:
def __semi_deepcopy__(self):
# These cannot be copied since they would both modify the same
# builder object, and indeed
# just copying would modify the original builder
raise TypeError( 'cannot semi_deepcopy a BuilderDict' )
...and reading this on the original issue (#2821):
> The problem is that the BUIDLERS are handled via a special BuilderDict which
> cannot be properly cloned. It has a deepcopy method, but the inherently alters
> the original environment to which it is attached.
> I tried a few different ways to correct this. The first was to workaround the
> issue during cloning, but it felt like it was mainly a hack. So I took the
> approach that the BuilderDict should not be copied directly, and made deepcopy
> throw an exception. The Clone function then manages a proper cloning of the
> BuilderDict.
...and the patch
(http://scons.tigris.org/nonav/issues/showattachment.cgi/890/patch.diff)
...I still don't completely understand the original problem. Why
exactly can't the BuilderDict be deep-copied? How does it alter the
attached environment?
Conceptually, why can't BuilderDict.__semi_deepcopy__ (or a regular
__deepcopy__ for that matter) know to actually create copies of the
Builders referenced by the BuilderDict as well?
More information about the Scons-dev
mailing list