[Scons-dev] 2.2.0 soon?

[Butler, Samuel D Capt USAF AETC AFIT/ENP]

REMOVE
 
Please remove me from this e-mail distribution list. I am not a Scons developer. I was a Scons user in the past, but I do not wish to receive any e-mails at this e-mail address.
 
Thanks!
 
V/R,
 
Samuel D. Butler, Capt, USAF
AFIT/ENP

________________________________

From: scons-dev-bounces at scons.org on behalf of Gary Oberbrunner
Sent: Fri 8/24/2012 1:03 PM
To: SCons developer list
Subject: Re: [Scons-dev] 2.2.0 soon?



On Fri, Aug 24, 2012 at 12:38 PM, Russel Winder <russel at winder.org.uk> wrote:

> Is this something that needs some planning and action so that it doesn't

> fall through the cracks?


Yes, for sure.  I don't have time right now to investigate it further,
but if someone could at least file a Tigris ticket for it that would
be a good start.  Any further actual work would of course also be
welcome :-)

-- Gary


> On Sun, 2012-07-29 at 15:34 -0400, Eric S. Raymond wrote:

>> Gary Oberbrunner <garyo at oberbrunner.com>:

>> > I agree about the importance of getting this in, but would like to

>> > push 2.2 out first.  Two reasons: 1, I think your patch will need some

>> > real-world testing in checkpoint releases for a while before we get it

>> > all right on all platforms, and I'd like to not hold 2.2 for that.

>>

>> That is reasonable.  I think this should be the top-priority new feature

>> for 2.3, though.  I believe the lack of it has been slowing down scons

>> adoption a *lot*.

>>

>> > And 2, the work needed to integrate it is more than I can do in a few

>> > hours: it needs tests and doc (I think both user guide and man page)

>> > at least.

>> >

>> > Have you created a Tigris ticket for it, with your patch?

>>

>> I have not, because I don't have anything I consider a final patch.

>> I never had a patch to scons itself; what I had was code that created

>> a pseudo-builtin in my recipe file.

>>

>> The reason I have not pursued this is because, as I said in my last

>> email, I now think having a separate versioned-shared-library builtin

>> may not be the right thing.  The profusion of builtins in scons is

>> bewildering and something of a problem; wouldn't it be better to have

>> SharedLibrary take a version argument and do the right thing?

>>

>> This goal makes a larger problem of the fact that I don't know your code

>> and I don't know your test frameworks.  It's probably about three

>> hours' work to fold this feature into SharedLibrary starting from my

>> code for someone who already knows your code, but I'd have to spend a

>> couple of days learning my way in first.  Sorry, but that just seems

>> like an inefficient and silly way to do things - and I'm swamped with

>> work on three other projects.

>>

>> Would someobody more on the inside take the lead on this, please?

>> I'm willing to help live-test the results and write documentation.

>

> --

> Russel.

> =============================================================================

> Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net

> 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk

> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

>

> _______________________________________________

> Scons-dev mailing list

> Scons-dev at scons.org

> http://two.pairlist.net/mailman/listinfo/scons-dev

>




--
Gary
_______________________________________________
Scons-dev mailing list
Scons-dev at scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev