Re: Why are Builders excluded from env.Clone()?

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 <[email protected]> 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?
_______________________________________________
Scons-dev mailing list
[email protected]
https://pairlist2.pair.net/mailman/listinfo/scons-dev