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 <tshor...@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? _______________________________________________ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev