Hum,
in fact, 1 and 3 and also the idea to checkin Scons 2.3 in our current code (as
well as all maintenance branches) are equivalent, and painful: We have many
maintenance branches, and hundreds of tags that potentially may have to be
checked out again and recompiled.
2 seems to be the only actual solution in order to keep all existing code
working.
However, what would you think about such implementation which keeps compatible
with current code:
- rename private attributes. example: abspath -> private_abspath
- for new code, use new interface. example: get_abspath() { return
self.private_abspath }
- for old code, allow using the old private attribute thanks to __getattr__():
class Node:
__slots__ = ('private_abspath')
def __init__(self):
self.private_abspath = None
def get_abspath(self):
self.private_abspath = "/a/path" # Lazy initialization
return self.private_abspath
def __getattr__(self, attr):
if attr == "abspath":
print "warning: abspath supported only for API consistency with
peformance loss. Use get_abspath()" # in real class,this warning should only be
printed once.
return self.get_abspath()
n = Node()
print n.get_abspath()
print n.abspath
result:
/a/path
warning: abspath supported only for API consistency with peformance loss. Use
get_abspath()
/a/path
Note: I always considered .path and .abspath as public API as they are
documented and used in many examples in the documentation. Was that a wrong
assumption?
> Le 2 mars 2015 à 09:30, Dirk Bächle <[email protected]> a écrit :
>
> Alexandre,
>
> On 02.03.2015 09:06, [email protected] wrote:
>> Hi Dirk,
>>
>> About those new interfaces for accessing node attributes that may get
>> initialized lazily, do I understand here the consequences properly?
>>
>> - Using directly a_node.path or a_node.abspath *must* be replaced in all
>> SConstructs/SConscripts by the new interfaces if we wan’t them to keep
>> working properly
>> - This lets us with 2 solutions:
>> 1- Do these changes in all our product maintenance branches, and even
>> each time we need to checkout again an old tag we want to compile again.
>> 2- Keep an old Scons 2.3 to build our old code, and change our build
>> infrastructure to be able to have different SCons paths, so we can chose the
>> proper one.
>>
>
> sorry, I forgot:
>
> 3- Factor out all your direct accesses to Node internals into a custom
> module/Builder, and then wrap it with a check for the SCons version. For
> 2.3.x and smaller, you access Node attributes as before, and for the newer
> versions you then branch to using the getter methods.
>
> This is pretty much what the compat layer would do, which I mentioned in my
> last reply.
>
> Best regards,
>
> Dirk
>
>
> _______________________________________________
> Scons-dev mailing list
> [email protected]
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
_______________________________________________
Scons-dev mailing list
[email protected]
https://pairlist2.pair.net/mailman/listinfo/scons-dev
