Hi Dirk,

So, I'm glad to say, I built without issue with your "switch_to_slots"
branch, so many thanks for this again.
While I was at it, I compared the memory usage on a full clean build (-j 8)
The flat period at the end is a post compilation step to create our
distribution, and the last brutal increase is probably caused by the
.sconsign.dblite creation.

Alexandre


2015-03-28 20:28 GMT+01:00 <alexan...@feblot.fr>:

> Hi Dirk,
>
> That’s great news. I’ll try that asap next week.
>
> Thanks a lot!
>
> Alexandre
>
> > Le 28 mars 2015 à 20:15, Dirk Bächle <tshor...@gmx.de> a écrit :
> >
> > Hi Alexandre,
> >
> > On 02.03.2015 09:06, alexandre.feb...@gmail.com 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.
> >>
> >
> > as you suggested, I implemented a simple backward compatibility layer
> using the "__getattr__" method. It's checked in to the same development
> branch "switch_to_slots" now. I also measured the speed of the new revision
> against the previous approach, and couldn't find any major impact.
> >
> > It would be very helpful if you could try and run this latest version
> against your production code. Please give us some feedback about whether
> this would work for you, and allows a flawless transition to the new
> version v2.4.
> >
> > Best regards,
> >
> > Dirk
> >
> > _______________________________________________
> > Scons-dev mailing list
> > Scons-dev@scons.org
> > https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
_______________________________________________
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Reply via email to