-
-
Notifications
You must be signed in to change notification settings - Fork 315
IrcLog2009 11 03
William Deegan edited this page Jan 14, 2016
·
2 revisions
16:19:19 * garyo (n=[[email protected]](mailto:[email protected])) has joined #scons
16:44:41 * Jason_at_intel (n=[[email protected]](mailto:[email protected])) has joined #scons
16:48:34 * bdbaddog (n=[[email protected]](mailto:[email protected])) has joined #scons
16:58:21 <Jason_at_intel> so Gary question
16:58:26 <garyo> yes?
16:58:30 <Jason_at_intel> the scons site stuff
16:58:38 <Jason_at_intel> is this planned for after 1.3?
16:59:00 <Jason_at_intel> 2.0?
16:59:01 <garyo> It seems to be coming together. I'd be OK stuffing it into 1.3 if I can get the time to turn a few strings into lists.
16:59:15 <garyo> Bill, what do you think?
17:00:17 <bdbaddog> how long til u think it'd be ready?
17:00:23 <garyo> I kind of would like to get it in early so people on weird OSes will say "hey, what about FooOS where it should be in /xyz/foo?"
17:00:37 <garyo> I could do it in a (long) night, really.
17:00:45 <garyo> Testing would take longer.
17:01:19 <garyo> The Windows dir-searching stuff is most of the work, but there's some code in the SEP already...
17:01:35 <bdbaddog> URL?
17:01:53 <garyo> MoreSiteSConsDirs in the wiki.
17:02:14 <Jason_at_intel> on the discussion page of this area is code for it
17:02:19 <garyo> (sorry, typing on one machine w/ spreadsheet etc. open in the other one, it's confusing)
17:02:32 <garyo> yes, Jason contributed a bunch of it.
17:02:09 * [GregNoel](GregNoel) is no longer marked as being away
17:02:49 <[GregNoel](GregNoel)> Hey, ho
17:03:06 <Jason_at_intel> Hi Greg!
17:03:42 <[GregNoel](GregNoel)> I'm a little under the weather; please excuse any slow typing tonight.
17:03:06 <garyo> btw, speaking of the wiki, you're all supposed to subscribe to the [BugParty](BugParty) page so you get an email when it gets updated. Hi Greg!
17:03:38 <garyo> Shall we get going? We clearly have a quorum.
17:03:52 <[GregNoel](GregNoel)> yes, start
17:03:59 <garyo> Jason, Bill, Gary, Greg, who'd I miss?
17:04:14 <bdbaddog> o.k. I'm subscribed to the page now.
17:04:19 <garyo> thx
17:04:21 <bdbaddog> Didn't know u could do that.. doh..
17:04:25 <Jason_at_intel> same..
17:04:31 * cdavid (i=82360a48@gateway/web/freenode/x-6ed6991a2ed30d5c) has joined #scons
17:04:34 <garyo> cool.
17:04:48 <garyo> Shall we dive into the bugs? It's been almost 3 months.
17:04:48 <[GregNoel](GregNoel)> 2427
17:04:51 <Jason_at_intel> Hi David!
17:04:57 <cdavid> Hi everyone
17:05:04 <cdavid> hope I am on time
17:05:05 <garyo> Hi David.
17:05:06 <bdbaddog> 4 time zones now represented :)
17:05:15 <garyo> :-)
17:05:29 <Jason_at_intel> 5 people?
17:05:45 <bdbaddog> btw. Heard from Steven - He wasn't sure if he'd make it tonight, but said not to wait for him on any decision.
17:05:55 <[GregNoel](GregNoel)> 2427, we agreed to document it, but didn't decide when
17:06:07 <bdbaddog> anytime?
17:06:08 <garyo> So let's doc 2427 ASAP.
17:06:12 <garyo> sure, anytime.
17:06:29 <[GregNoel](GregNoel)> OK, who? and priority?
17:06:44 <bdbaddog> I'll take it.
17:06:48 <garyo> thanks!
17:06:52 <[GregNoel](GregNoel)> priority?
17:07:03 <garyo> p3?
17:07:09 <[GregNoel](GregNoel)> worksforme
17:07:31 <[GregNoel](GregNoel)> 2443
17:08:25 <bdbaddog> is this taskman stuff?
17:08:31 <garyo> we looked at this last time. I thought line 699 of Action.py was a bug, Greg thought it was OK.
17:08:56 <[GregNoel](GregNoel)> No, Steven thought it was OK.
17:09:02 <garyo> (ok, sorry)
17:09:33 <[GregNoel](GregNoel)> There are two subst_list()s in different places.
17:09:14 <garyo> I say too late for 1.3, but p1 or p2 for 2.0.
17:09:21 <garyo> Steven or me.
17:09:24 <Jason_at_intel> honestly in Part i use action in Aliases a bit.. would break if they did not work
17:10:21 <[GregNoel](GregNoel)> 2.0 p2/3 garyo since Steven is so busy
17:10:25 <garyo> well his [TypeError](TypeError) is coming from *somewhere*. Anyway, we can figure it out when we fix it, but it's clear there's some case that doesn't work.
17:10:29 <garyo> OK w/ me.
17:10:35 <bdbaddog> +1
17:10:48 <[GregNoel](GregNoel)> done
17:10:52 <[GregNoel](GregNoel)> 2444
17:11:11 <garyo> anytime, p4?
17:11:18 <[GregNoel](GregNoel)> ok, who?
17:12:01 <bdbaddog> I'll take it. Got one doc bug, another won't be much more pain.
17:12:06 <[GregNoel](GregNoel)> done
17:12:11 <[GregNoel](GregNoel)> 2445
17:12:44 <garyo> bug's invalid, but left there for python minversion discussion, right?
17:12:57 <[GregNoel](GregNoel)> I've fixed a couple and I have one queued up.
17:13:10 <bdbaddog> yes. So let's stick logic in to check 1.5.2 < current version < 3.0 ?
17:13:28 <garyo> That sounds simple enough.
17:13:44 <[GregNoel](GregNoel)> Er, 2.4 < ver < 3.0
17:13:47 <bdbaddog> we have the deprecation and such logic there already so shouldnt' be too bad. go ahead an assign to me.
17:13:59 <bdbaddog> for 1.3 , 1.5.2 < curr < 3.0, for 2.0 as you said.
17:14:17 <[GregNoel](GregNoel)> 1.3 p(what?)
17:14:29 <garyo> Yes. Bill, you have time to stick that check in soonish?
17:14:35 <bdbaddog> yes.
17:14:43 <garyo> +1
17:14:58 <[GregNoel](GregNoel)> p2 then? or p1?
17:15:04 <garyo> p2
17:15:07 <bdbaddog> plus 2.0 might take a bit to get out and 3.0, 3.1 will become more common.
17:15:11 <bdbaddog> p1.
17:15:18 <garyo> your call.
17:15:26 <[GregNoel](GregNoel)> p1, done
17:15:28 * jesterKing is now known as amino
17:15:35 <[GregNoel](GregNoel)> 2446
17:16:07 <[GregNoel](GregNoel)> only two comments; skip
17:16:12 <[GregNoel](GregNoel)> 2447
17:16:23 <[GregNoel](GregNoel)> only two comments; skip
17:16:35 <[GregNoel](GregNoel)> 2448
17:17:06 <bdbaddog> 2.x ?
17:17:07 <garyo> 3.x p3 unless Ken has a patch.
17:17:21 <bdbaddog> 3.x is fine. we could pull in if a patch appears.
17:17:24 <[GregNoel](GregNoel)> agree w/ gary
17:17:25 <garyo> (Bill, I'd love to have it earlier, but who would do it?)
17:17:54 <bdbaddog> I'm fine with 3.x
17:17:47 <[GregNoel](GregNoel)> I'll put ken on it; anybody want CC?
17:18:05 <bdbaddog> CC ?
17:18:10 <bdbaddog> cc on the bug?
17:18:15 <[GregNoel](GregNoel)> yes
17:18:24 <Jason_at_intel> yes
17:18:29 <bdbaddog> yes
17:18:39 <[GregNoel](GregNoel)> done
17:18:45 <[GregNoel](GregNoel)> 1449
17:18:56 <garyo> 2449 :-)
17:19:11 <[GregNoel](GregNoel)> oops, yes
17:19:13 <cdavid> can we use subprocess ? I am a bit confused by the version requirements of scons
17:19:30 <bdbaddog> 1.5.2 < current version < 3.0 for 1.3
17:19:35 <Jason_at_intel> 2.4 subprocess should be good
17:19:41 <bdbaddog> 2.4 < current version < 3.0 for 2.0
17:19:42 <cdavid> so we cannot use subprocess ?
17:19:46 <cdavid> for 1.3
17:19:47 <bdbaddog> nope. not for 1.3
17:19:48 <Jason_at_intel> plus we can remove the open() hack on teh win32 platform
17:19:49 <[GregNoel](GregNoel)> Subprocess is not the issue; we already have a backward-compatible version we're using now.
17:19:55 <Jason_at_intel> fixes issues on win7
17:19:59 <garyo> but we start working on 2.0 as soon as 1.3 is out the door
17:20:13 <bdbaddog> yes. 2.0/2.x for 2449
17:20:44 <[GregNoel](GregNoel)> not 2.0; that's only bug fixes and removing backward compatibility.
17:21:02 <bdbaddog> isn't this a bug fix?
17:21:15 <Jason_at_intel> agree
17:21:16 <[GregNoel](GregNoel)> No, it's an issue
17:22:23 <[GregNoel](GregNoel)> I should have said *trivial* bug fixes, as in fixes to documentation.
17:21:36 <Jason_at_intel> is it not.. since you have a subprocess copy in SCons
17:21:36 <garyo> I'd like to put as little into 2.0 as we can and just break back compat, *then* start on new stuff to build on that base.
17:21:39 <[GregNoel](GregNoel)> Yes, that's the intent.
17:21:40 <bdbaddog> -j sometimes breaks on windows seems like a bug.
17:21:51 <Jason_at_intel> I woudl think we would rather use the Scons version if we could
17:21:53 <bdbaddog> how hard to swap to subprocess ?
17:22:10 <bdbaddog> 2.1 then?
17:22:11 <Jason_at_intel> it easy.. it the SPAWN functions
17:23:04 <[GregNoel](GregNoel)> If it were that easy, we'd have done it already. It's not.
17:22:51 <bdbaddog> lets mark it 2.x, and hold on the waht goes into 2.0 discussion?
17:23:22 <Jason_at_intel> no.. you have not moved to Python 2.4 as a base requiremnet
17:23:27 <bdbaddog> I though we were precluded because of 1.5.2 compat requirement
17:23:31 <Jason_at_intel> in Parts we require 2.5 or better
17:23:51 <Jason_at_intel> we use Subprocess via replacing SPAWN with our version
17:23:51 <bdbaddog> Let's mark it 2.x and move on?
17:24:03 <bdbaddog> we can pull it in if it's easy.
17:24:04 <Jason_at_intel> it works great.. we even colorize output now
17:24:20 <[GregNoel](GregNoel)> Seeing no consensus, consider next time
17:24:34 <Jason_at_intel> wait till 2.0 .. it will not hurt
17:24:49 <garyo> Greg, let's mark it 2.x and move on.
17:24:58 <bdbaddog> +1 2.x
17:25:07 <[GregNoel](GregNoel)> garyo, what priority?
17:25:16 <bdbaddog> p2
17:25:16 <garyo> p1 or p2, it's big.
17:25:19 <bdbaddog> p1
17:25:20 <garyo> ok, p2
17:25:23 <bdbaddog> p2
17:25:25 <garyo> ok, p1
17:25:29 <garyo> :-)
17:25:36 <bdbaddog> ok p1.
17:25:40 <[GregNoel](GregNoel)> p1 is for emergencies; p2
17:25:44 <bdbaddog> p2
17:25:46 <garyo> fine
17:25:49 <bdbaddog> fine
17:26:07 <[GregNoel](GregNoel)> who?
17:26:17 <garyo> Jason, could you try it?
17:26:17 <bdbaddog> Jason?
17:26:30 <[GregNoel](GregNoel)> or make it part of the 2.x discussion?
17:26:36 <Jason_at_intel> is this 2449
17:26:42 <bdbaddog> yup
17:26:45 <cdavid> I could also look at it - I think I have tried using subprocess in scons
17:26:49 <Jason_at_intel> I can give you a patch
17:27:01 <cdavid> and I use -j option quite a bit on windows nowadays
17:27:04 <garyo> ok, David w/ jason as cc?
17:27:14 <[GregNoel](GregNoel)> yes, sounds good
17:27:18 <bdbaddog> +1
17:27:19 <[GregNoel](GregNoel)> done
17:27:26 <[GregNoel](GregNoel)> 2450
17:28:05 <garyo> I like this one.
17:28:31 <garyo> I think we should just put it in in 2.x. I'll do it.
17:28:36 <bdbaddog> +1
17:28:41 <[GregNoel](GregNoel)> I think it's badly entangled with 2446 and 2447, but if you want it, go for it.
17:28:45 <[GregNoel](GregNoel)> what priority?
17:28:49 * stevenknight (n=[[email protected]](mailto:[email protected])) has joined #scons
17:28:52 <garyo> I don't think it's that tangled.
17:28:54 <bdbaddog> p3 or p4 ?
17:28:58 <garyo> Hi Steven!!!
17:29:02 <Jason_at_intel> Hi steve
17:29:06 <stevenknight> hey guys
17:29:11 <garyo> How are you?
17:29:15 <[GregNoel](GregNoel)> Steven, we're considering 2450
17:29:17 <Jason_at_intel> long time no see!
17:29:19 <stevenknight> been better
17:29:22 <stevenknight> yeah
17:29:29 <stevenknight> sick kid *and* a sick laptop today
17:29:35 <garyo> :(
17:29:47 <bdbaddog> hmm. laptop got H1n1 ?
17:30:35 <stevenknight> bdbaddog: maybe, google remote tech support was stymied
17:30:43 <stevenknight> let me get caught up with you all
17:30:52 <stevenknight> (don't wait, though)
17:31:16 <cdavid> hi steven
17:29:01 <garyo> p3's fine.
17:30:15 <[GregNoel](GregNoel)> what priority?
17:30:21 <[GregNoel](GregNoel)> p3?
17:30:24 <garyo> 2450? p3.
17:30:28 <Jason_at_intel> p3?
17:30:26 <[GregNoel](GregNoel)> done
17:30:35 <[GregNoel](GregNoel)> 2451
17:31:23 <[GregNoel](GregNoel)> Gary, you're the expert on this one
17:31:18 <Jason_at_intel> so Gary did you think this was doable in 1.3
17:31:28 <Jason_at_intel> at least an early drop of it?
17:31:35 <garyo> so 2451: I'll try to put in the new site_scons dirs for 1.3, that'll help. The rest is toolchain related.
17:32:04 <[GregNoel](GregNoel)> Uh, I'd resist 1.3; already too delayed.
17:32:07 <garyo> I guess I don't feel that strongly about the module/package thing.
17:32:37 <garyo> How about if I *try* to get it into 1.3, given a late night, but don't hold 1.3 for it.
17:32:47 <bdbaddog> so "anytime"
17:32:54 <Jason_at_intel> good for me
17:32:57 <garyo> I guess that's right.
17:33:04 <bdbaddog> +1
17:33:16 <stevenknight> hey cdavid
17:33:19 <[GregNoel](GregNoel)> I don't like possibly destabilizing 1.3; 2.1?
17:33:31 <garyo> We
17:33:35 <garyo> (sorry)
17:34:02 <[GregNoel](GregNoel)> (and here I thought you were talking about my new Wii)
17:34:01 <bdbaddog> anytime pending code review into 1.3? otherwise 2.1?
17:34:03 <garyo> If we do another drop with David's code, I can put it into that. If it causes any issues, I'll back it out for 1.3. OK?
17:34:09 <stevenknight> at this point, i'd think 1.3 should be cut to bare minimum
17:34:38 <[GregNoel](GregNoel)> concur with stevenknight
17:34:14 <cdavid> what are the big things for 1.3 ? Just releasing what's out there in the trunk ?
17:34:20 <cdavid> I mean the goal of 1.3.0 ?
17:34:30 <garyo> msvc!
17:34:36 <bdbaddog> let's punt til 5:50 for 1.3 discussion?
17:34:37 <cdavid> ok
17:35:03 <garyo> OK, I'll hold back on the site_scons stuff. No prob.
17:35:14 <Jason_at_intel> 2.x then
17:35:30 <garyo> Yes, probably early like 2.1.
17:35:32 <[GregNoel](GregNoel)> consensus? 2.1? what priority?
17:35:37 <bdbaddog> 2.1 p3 ?
17:35:40 <garyo> p3
17:35:44 <stevenknight> 2.1 p3
17:35:44 <[GregNoel](GregNoel)> done
17:36:00 <[GregNoel](GregNoel)> 2452
17:36:38 <bdbaddog> future p1 for 2452
17:36:50 <cdavid> if 2.0 should only do backward incompatible changes, this would be 3.x ?
17:37:10 <bdbaddog> there's 2.x
17:37:17 <bdbaddog> and 2.1
17:37:23 <[GregNoel](GregNoel)> I'd like to assign Ludwig, but suggest very strongly that he work with Ken, since they have complementary insights on this
17:37:24 <garyo> right.
17:37:34 <bdbaddog> +1
17:37:38 <garyo> +1
17:37:52 <stevenknight> +1 and I'll raise another +1
17:38:06 <Jason_at_intel> so when is 3.x?
17:38:07 <[GregNoel](GregNoel)> Not 3.x; it's all internal, no user API affected
17:38:29 <Jason_at_intel> I agree with that
17:38:42 <Jason_at_intel> seen like a 2.x thing
17:38:46 <bdbaddog> so 2.x then or future? depends when we have a solution.
17:38:56 <bdbaddog> +1 2.x p1
17:39:03 <Jason_at_intel> +1
17:39:07 <stevenknight> 2.x p1
17:39:08 <[GregNoel](GregNoel)> 2198 already has a patch, but I want Ken to refine it.
17:39:31 <garyo> ok, maybe he can roll them all together.
17:39:39 <[GregNoel](GregNoel)> 2.x p2, it's not an emergency
17:39:48 <garyo> agreed.
17:40:11 <stevenknight> good point
17:39:49 <bdbaddog> +1 p2
17:40:15 <[GregNoel](GregNoel)> done
17:40:23 <[GregNoel](GregNoel)> 2453
17:40:40 <bdbaddog> 2.x p3
17:40:54 <garyo> ok w/ me
17:41:11 <garyo> Ludwig/Ken or Ken/Ludwig :-/
17:41:37 <[GregNoel](GregNoel)> Ludwig/Ken; I have confidence that Ludwig will close it.
17:42:10 <[GregNoel](GregNoel)> No other objections? Done 2.x p3 Ludwig
17:42:16 <[GregNoel](GregNoel)> 2454
17:42:32 <garyo> Ken should just do this. It's easy.
17:42:42 <garyo> "Please submit a patch."
17:42:47 <[GregNoel](GregNoel)> Same stuff, same comments from me
17:42:55 <bdbaddog> 2.x p3 then?
17:42:59 <garyo> 2.x p3 Ken?
17:43:07 <stevenknight> sounds good
17:43:09 <[GregNoel](GregNoel)> I'd go with Ludwig
17:43:15 <garyo> (at least Ken to submit the patch?)
17:43:22 <[GregNoel](GregNoel)> I'll buy that
17:43:31 <bdbaddog> +1
17:43:34 <stevenknight> +1
17:43:37 <[GregNoel](GregNoel)> done
17:43:43 <[GregNoel](GregNoel)> 2455
17:44:13 <[GregNoel](GregNoel)> Looks like consensus research garyo
17:44:18 <[GregNoel](GregNoel)> what priority?
17:44:20 <garyo> OK.
17:44:28 <garyo> p3 or p4
17:44:38 <bdbaddog> p4
17:44:40 <cdavid> this would better be done at the same time as fixing configure IMO
17:44:41 <stevenknight> p4 if either is ok
17:44:51 <[GregNoel](GregNoel)> p4
17:44:52 <[GregNoel](GregNoel)> done
17:44:59 <[GregNoel](GregNoel)> 2455
17:45:01 <garyo> cdavid: what other configure fixes are related?
17:45:54 <cdavid> configure does not use the same process as normal scons, so everytime you change your configure context, scons is confused
17:45:54 <garyo> anyway I think this particular issue is easily solved.
17:46:26 <stevenknight> cdavid: agree, but that'll take a while to fix
17:46:39 <bdbaddog> so research, garyo, p4 ?
17:46:44 <garyo> cdavid: it's true, configure is a bit "unusual" in how it interacts w/ scons. But I can fix 2455 in limited time, fixing configure is... harder.
17:46:44 <[GregNoel](GregNoel)> I agree with cdavid that fixing configure would fix this, but it needs to be solved sooner.
17:46:56 <stevenknight> research garyo p4
17:46:57 <cdavid> yes, it will take time, but fixing confdefs without fixing configure seems wasteful
17:46:57 <garyo> bdbaddog: +1
17:47:25 <garyo> cdavid: nah, it's just a missing string assignment somewhere or something like that.
17:47:44 <garyo> It's not like configure isn't useful as it is, a lot of people use it.
17:47:48 <[GregNoel](GregNoel)> p4
17:48:04 <cdavid> ah, sorry, I thought it required adding a new arg to [CheckHeader](CheckHeader), I was confused by the different use cases on the wiki
17:48:37 <garyo> cdavid: that's the weird part; all the HAVE_XXX logic is all in there. It just never gets out properly.
17:48:05 <garyo> 2456: done.
17:48:11 <stevenknight> 2457
17:48:24 <bdbaddog> 2.x p3, me
17:48:38 <stevenknight> I like russel's suggestion, make it qt3 with qt as a backwards compatible alias?
17:48:52 <bdbaddog> +1 alias, with deprecation notice?
17:48:58 <stevenknight> yeah
17:49:03 <[GregNoel](GregNoel)> concur
17:49:02 <bdbaddog> most all new qt work will be qt4
17:49:39 <bdbaddog> I'm hoping qt40,41,42,43,45 won't be necessary
17:49:42 <[GregNoel](GregNoel)> 2.x p3 bdbaddog?
17:49:46 <bdbaddog> +1
17:49:51 <stevenknight> done
17:49:56 <[GregNoel](GregNoel)> done
17:50:06 <[GregNoel](GregNoel)> 2458
17:50:34 <garyo> invalid.
17:50:55 <garyo> can say: "sorry, we can't change it at this point."
17:50:58 <[GregNoel](GregNoel)> invalid
17:51:07 <bdbaddog> invalid, though once we rationalize tools/platofrms.. we might be able to handle better.
17:51:07 <stevenknight> i can live with that
17:51:11 <[GregNoel](GregNoel)> "and wait for new configure"
17:51:18 <Jason_at_intel> these can be overridden
17:51:26 <stevenknight> note added to doc, though?
17:51:40 <stevenknight> seems like potentially a common enough stumbling point
17:51:50 <garyo> not a bad idea.
17:51:45 <[GregNoel](GregNoel)> who, when?
17:51:59 <garyo> Bill, since you're doc guy today... ?
17:52:06 <bdbaddog> +1 doc, all we have to say is add -fwin32 for win32 right?
17:52:16 <stevenknight> believe so
17:52:13 <bdbaddog> yup. sign me up.
17:52:16 <[GregNoel](GregNoel)> could be 1.3 or 2.0
17:52:22 <[GregNoel](GregNoel)> if it's only doc
17:52:25 <bdbaddog> so anytime.
17:52:35 <bdbaddog> so anytime, p3, Bill
17:52:39 <[GregNoel](GregNoel)> done
17:53:01 <bdbaddog> how much more time does everyone have?
17:53:17 <garyo> I don't have to go anytime soon.
17:53:17 <bdbaddog> wanted to talke for 10 minutes about 1.3 before we all head off.
17:53:23 <Jason_at_intel> I am good
17:53:41 <[GregNoel](GregNoel)> I've got maybe 30 more minutes
17:53:57 <stevenknight> i'm okay for a while
17:53:58 <bdbaddog> ok. let's go mabye 10 more on bugs and then talke about 1.3 ?
17:54:00 <garyo> ok, let's stop at 10 after and talk about 1.3
17:54:02 <[GregNoel](GregNoel)> I'd like to finish these if possible
17:54:03 <bdbaddog> +1
17:54:13 <stevenknight> (positive side to laptop dying: i can't do any day-job work... :-))
17:54:16 <cdavid> fine by me
17:52:51 <[GregNoel](GregNoel)> 2459
17:52:59 <garyo> invalid, imho.
17:53:24 <[GregNoel](GregNoel)> invalid
17:53:37 <bdbaddog> +1 invalid
17:54:58 <Jason_at_intel> 2459 seem invalid to me
17:53:53 <[GregNoel](GregNoel)> done
17:54:55 <[GregNoel](GregNoel)> 2460
17:55:30 <bdbaddog> 2460, 2.x, who, p2 ?
17:56:06 <Jason_at_intel> I agree that i would rather have Depends work with Alias.. not alias another alias
17:56:35 <garyo> Sure, Depends should work, but this kind of stuff can get complicated. If Steven could do it...
17:56:39 <Jason_at_intel> this seems to be a node issue.. who does the node code?
17:57:37 <garyo> I think it'd have to be Steven, or else 3.x when someone else may have time/knowledge.
17:57:45 <[GregNoel](GregNoel)> concur
17:57:50 <garyo> So that's why I said 3.x p3.
17:57:52 <Jason_at_intel> +1
17:57:56 <bdbaddog> +1
17:58:04 <stevenknight> go ahead and put my name on it
17:58:03 <[GregNoel](GregNoel)> done
17:58:32 <stevenknight> i'm going to go through my issues and re-prioritize, give back ones that others can do
17:59:04 <garyo> steven: ok, make a list of what needs to be re-triaged.
17:59:18 <stevenknight> garyo: will do
17:58:32 <bdbaddog> 2461, invalide
17:58:32 <garyo> 2461 looks invalid.
17:58:37 <[GregNoel](GregNoel)> done
17:59:07 <[GregNoel](GregNoel)> 2462
17:59:18 <cdavid> I can reproduce 2462
17:59:45 <cdavid> but in a big project only - I can try to make a small reproducible script to track it down
17:59:29 <bdbaddog> 2.1,p1, who?
17:59:49 <garyo> cdavid: me too. I'll take it, I fixed another one like it once.
17:59:54 <cdavid> ok
18:00:02 <Jason_at_intel> I have not seen this yet
18:00:23 <garyo> Happens when you rename or delete things and the .sconsign has a ref to them, typically.
18:00:36 <garyo> ... and if Glob is involved it's more likely.
18:00:52 <Jason_at_intel> ahh we don't use GLob
18:00:34 <[GregNoel](GregNoel)> garyo with cdavid as CC? 2.1, p1
18:00:38 <[GregNoel](GregNoel)> er, p2
18:00:44 <garyo> p2, thanks.
18:00:50 <cdavid> fine by me
18:00:51 <bdbaddog> 2.1, p2, garyo ?
18:01:00 <Jason_at_intel> +1
18:01:01 <[GregNoel](GregNoel)> done
18:01:08 <[GregNoel](GregNoel)> 2463
18:01:27 <bdbaddog> 2.x, garyo, p3 ?
18:01:29 <garyo> I'll remove it in 2.x (or even 2.1).
18:01:31 <[GregNoel](GregNoel)> 2.x p3 garyo
18:01:51 <[GregNoel](GregNoel)> do you want 2.1 or 2.x?
18:02:09 <garyo> 2.1.
18:02:11 <[GregNoel](GregNoel)> done
18:02:20 <[GregNoel](GregNoel)> 2465
18:02:37 <bdbaddog> 1.3,me, p2 or p3
18:02:50 <garyo> I'm ok w/ 1.3 since it's only bootstrap.py.
18:03:00 <[GregNoel](GregNoel)> OK, done
18:03:14 <garyo> woo hoo!
18:03:21 <[GregNoel](GregNoel)> and now for the 1.3 discussion...
18:03:28 <bdbaddog> :D
18:03:40 <bdbaddog> o.k. what's left? how much msvc stuff?
18:04:04 <garyo> I think we should seriously consider David's simplifications.
18:04:04 <Jason_at_intel> what are the issues?
18:04:05 <cdavid> there is the "how to deal with error" stuff
18:04:13 <Jason_at_intel> 1)cross build
18:04:17 <Jason_at_intel> 2) SDK?
18:04:18 <garyo> ... with a bit of error handling.
18:04:26 <garyo> Ah yes, SDK.
18:04:31 <cdavid> cross build works for me
18:04:40 <cdavid> SDK is much more difficult
18:04:48 <garyo> Cross build should work for me, but I have a test-machine issue. :-/
18:04:55 <garyo> (w/ David's version)
18:05:02 <Jason_at_intel> I view SDK as have the users add it to tools they load
18:05:14 <garyo> +1, make users add it.
18:05:14 <Jason_at_intel> once we get toolchains then it will be easier
18:05:15 <cdavid> that would make the problem go away :)
18:05:28 <cdavid> ok, so don't handle sdk automatically
18:05:39 <Jason_at_intel> yes, let the user add it
18:05:42 <cdavid> what's the best way to print a user warning ?
18:05:44 <garyo> Does setting MSSDK_VERSION do it?
18:06:01 <Jason_at_intel> this way they can control is it add it stuff before or after the compiler lines
18:06:06 <cdavid> no, you would have to use the mssdk tool
18:06:25 <garyo> cdavid: oh yeah. That's fine.
18:06:26 <cdavid> so MSSDK_VERSION would control it, but you would have to explicitly load the mssdk tool
18:06:26 <Jason_at_intel> MSSDK_VERSION set which version you setup
18:06:46 <garyo> Needs to be documented
18:07:02 <cdavid> ah, I forgot about msvs
18:07:12 <cdavid> what's the need for MSVS_VERSION and MSVC_VERSION ?
18:07:14 <Jason_at_intel> so mssdk issue
18:07:19 <Jason_at_intel> agreeded?
18:07:23 <cdavid> agreed
18:07:26 <garyo> Jason: yes.
18:07:52 <cdavid> in the trunk, both vs and vc code look for a batch file
18:08:03 <cdavid> I don't know the rationale for this - I don't do it in the cleaned up branch
18:08:05 <garyo> cdavid: I always thought MSVS_VERSION was for making Visual Studio projects, but I don't really know.
18:08:06 <Jason_at_intel> so there was a talk that MSVS_VERSION is for teh project generation and the MSVC_VERSION is the compiler
18:08:27 <garyo> I'd be happy if we can make that true.
18:08:42 <cdavid> currently, my understanding is that MSVS_VERSION control devenv path
18:08:52 <garyo> ... which is what?
18:08:55 <garyo> IDE?
18:08:59 <cdavid> yes
18:09:07 <cdavid> you can build at the command line as well:
18:09:13 <cdavid> devenv foo.sln /build "Release"
18:09:22 <cdavid> which is my only use of the IDE, personally :)
18:09:24 <Jason_at_intel> that is a custom command
18:09:35 <garyo> got it. But still related to "solution generation", not compiler.
18:09:36 <cdavid> but this command is found by the msv*c* batch file
18:09:58 <garyo> ack
18:10:08 <Jason_at_intel> ??
18:10:12 <cdavid> the problem is that currently, if MSVS* and MVSC* refer to different version, the environment is screwed up
18:10:13 <Jason_at_intel> found?
18:10:36 <cdavid> sorry, I meant if the msvc batch file is executed, devenv will be in the path
18:10:42 <garyo> cdavid: aha, that explains a lot.
18:10:54 <Jason_at_intel> yes that is true
18:11:11 <Jason_at_intel> even if you did what i have.. this would be true
18:11:21 <garyo> (like the SCONS_MSCOMMON_DEBUG trace I sent you earlier today)
18:11:25 <cdavid> the msvs project stuff requires any IDE stuff ?
18:11:34 <cdavid> or is it pure python code ?
18:11:40 <garyo> So what I'm hearing is MSVS_VERSION and MSVC_VERSION cannot realistically be different.
18:11:59 <garyo> at least how things are today.
18:12:05 <cdavid> it could if MSVS_VERSION would only control project generation, assuming project generation does not depend on any external tool
18:12:05 <Jason_at_intel> I think msvs is just python code
18:12:49 <garyo> So let's move in that general direction.
18:13:00 <Jason_at_intel> Steve.. do you have a better project generator for vs?
18:13:00 <cdavid> What about having a new variable to control the project generation, and deprecate MSVS_VERSION ?
18:13:00 <bdbaddog> but can we make the MSVS_VERSION change in 1.3?
18:13:11 <garyo> How about if we make sure that the msvs bat file doesn't get loaded by default?
18:13:27 <Jason_at_intel> I thought you said on the phone a long time ago that there was a native project generator in the works
18:13:57 <garyo> bdbaddog: maybe too short a time scale to do it all.
18:14:00 <Jason_at_intel> cdavid : agree
18:14:05 <cdavid> @garyo: yes, the msvs batch file would never be loaded, and if MSVS_VERSION is set by the user, we would print a warning (if MSVS_VERSION is set as well)
18:14:29 <garyo> How about for 1.3 we just say MSVC_VERSION and MSVS_VERSION should be the same.
18:14:38 <garyo> (or MSVS_VERSION unset)
18:14:57 <garyo> cdavid: +1
18:14:59 <cdavid> so the cases would be: 1: by default, do nothing, set MSVS_VERSION and MSVC_VERSION", 2: if MSVC_VERSION xor MSVC_VERSION set, set the tool to this version 3: if both are set and different, raise an error
18:15:01 <bdbaddog> SO if we take David's patch(s), and deprecate and ignore MSVS_VERSION in 1.3, are we far away from being done?
18:15:02 <Jason_at_intel> I think we want to migrate allow both.. but preffer MSVC_
18:15:29 <Jason_at_intel> if both are set
18:15:38 <garyo> I like David's way. @bdbaddog: we just need error checking, which I have some of.
18:16:10 <cdavid> I think the main issue is testing
18:16:15 <garyo> David, I'll send you my error patch; can you do the MSVS_/MSVC_ stuff and update your git repo? Then we can all test.
18:16:19 <cdavid> yes
18:16:31 <cdavid> my changes are in the msvc_changes branch, BTW - master tracks the trunk
18:16:45 <garyo> cdavid: thanks, I'll check that.
18:16:51 <bdbaddog> o.k. can we put a matrix in the wiki which which combos of host/target's we can test with which VS & VC versions?
18:17:14 <cdavid> I think Jason started something in that direction, right ?
18:17:25 <garyo> Jason, don't you have some VMs?
18:17:26 <cdavid> which page, I don't remember
18:17:41 <Jason_at_intel> I need to put it online.. and it was for Parts work with the new tool chain stuff
18:17:51 <cdavid> I have a xp 64 vm with VS 2008, a xp32 vm with 2010, and a windows 7 vm with 2008
18:18:09 <bdbaddog> so we have no 2003, 2005, or vs6 ?
18:18:17 <Jason_at_intel> so it does not test the Scons version of the tools
18:18:18 <cdavid> I have VS 2003 somewhere
18:18:24 <garyo> I have VS 2003 & 2005 on the same machine, and some other stuff. Maybe an old vs6 machine or vm.
18:18:31 <cdavid> vs 6 is harder
18:18:35 <Jason_at_intel> I have vc6 -2008
18:18:52 <bdbaddog> can any of these be setup as buildbot slaves? ;)
18:19:03 <cdavid> not in my case, as it is on my laptop
18:19:03 <garyo> The tests have to be run manually though, for now.
18:19:25 <garyo> Mine are "corporate" and I don't think I can put buildbot on them.
18:19:26 <cdavid> you can automatically get the tarballs from github, at least
18:19:33 <Jason_at_intel> I was going to setup a bug for you .. but am having time issues with work processes in our build, and there is a security concern the IT has that I ahve to fix
18:19:36 <stevenknight> (bdbaddog: speaking of buildbot, master's down. i logged in to the system, any reason not to restart master?)
18:19:48 <Jason_at_intel> mean time i can test manually and report out
18:20:04 <bdbaddog> (steve: no reason not to restart, need to figure out why it's not restarting at reboot)
18:20:07 <garyo> Jason, you saw David's testcase hello.c/SConstruct, right?
18:20:23 <Jason_at_intel> nope
18:20:31 <garyo> I'll forward it to you.
18:20:34 <Jason_at_intel> ok
18:21:07 <Jason_at_intel> run it and give you the outputs?
18:21:10 <garyo> OK, so once that's all squared away, we put out another ckpoint?
18:21:16 <bdbaddog> yes.
18:21:16 <garyo> Jason: it'll be obvious.
18:21:19 <cdavid> yes
18:21:22 <Jason_at_intel> ok
18:21:26 <bdbaddog> then 2 weeks then 1.3
18:21:28 <Jason_at_intel> will wait to get it and see then
18:21:35 <cdavid> I will clean up a few things in the branch, normalize MSVC/MSVS
18:21:39 <cdavid> for the warnings ?
18:21:50 <cdavid> I try to use scons warnings but could not get them to pring
18:21:56 <cdavid> using SCons.warning
18:21:58 <garyo> I'll send you what I have which deals with missing cross-architectures
18:22:20 <garyo> but I use SCons.Error for a manually-specified missing TARGET_ARCH.
18:22:45 <garyo> Warnings don't print unless they're enabled by default somewhere.
18:22:50 <garyo> SCons.Warnings or something?
18:22:51 <Jason_at_intel> you mean bad TARGET_ARCH?
18:23:17 <garyo> Jason: uninstalled TARGET_ARCH, like I don't have the x86-64 compiler installed on my VS2003 machine.
18:23:39 <Jason_at_intel> ahh tool setup combo that can 't be done
18:23:46 <garyo> one other thing, there's a nice arch.py in mscommon, but I don't think it's used.
18:23:57 <Jason_at_intel> I do the same I think i have a toolset error based on Scons [UserError](UserError)
18:24:01 <garyo> (hm, maybe I was looking on trunk though.)
18:24:13 <garyo> Jason: right.
18:24:22 <cdavid> I have changed arch.py
18:24:29 <cdavid> using dict instead of objects
18:24:37 <Jason_at_intel> I thought arch was moved to Platform?
18:25:00 <cdavid> the best would be to push this in a more general manner for cross compilation on any platform
18:25:02 <garyo> ok.
18:25:13 <stevenknight> cdavid: Script/Main.py has the list of warnings enabled by default
18:25:16 <cdavid> but currently, I don't see this happening with the current tool infrastructure
18:25:17 <bdbaddog> agreed, but let's minimize the changes for 1.3
18:25:41 <cdavid> so we can keep the arch values in the MS tools subdirectory for now ?
18:25:53 <garyo> @cdavid: right, impossible in limited time.
18:26:05 <Jason_at_intel> cdavid: have you seen what i did in Parts for this? based on current tool stuff?
18:26:27 <Jason_at_intel> it may not be that hard in reality
18:26:27 <cdavid> jason: I have started looking at the doc, but did not have the time to really go deep down
18:26:47 <Jason_at_intel> if you get time and have question/thought let me know
18:26:55 <[GregNoel](GregNoel)> (Got to go; dinner imminent. Since I don't seem to be contributing here, you shouldn't miss me. {;-} I'll read through what I missed later.)
18:26:58 <cdavid> steven: thanks, I will look there
18:27:32 <cdavid> I think I will send an email on the dev ML once I have done everything we have discussed, and maybe integrating gary's fixes
18:27:33 <Jason_at_intel> ok so for 1.3
18:28:17 <bdbaddog> guestimate on timeline?
18:28:35 <cdavid> I will do all the fixes discussed now within today
18:28:37 <garyo> it'll take a couple of days to test, I'll get my stuff to David tomorrow
18:28:43 <cdavid> so tomorrow for people in the US
18:28:43 <Jason_at_intel> 1) SDK - fixed
18:28:45 <Jason_at_intel> 2) testing needed .. but we think it is about there
18:28:46 <Jason_at_intel> 3)MSVC_ MSVS_ do what David suggests
18:28:48 <Jason_at_intel> 4) TARGET_ARCH??
18:28:56 <cdavid> it is done
18:28:58 <garyo> TARGET_ARCH is working now.
18:29:01 <cdavid> I mean TARGET_ARCH is working
18:29:25 <cdavid> TARGET_HOST/TARGET_ARCH works for all combinations x86/amd64 with VS 2008
18:29:32 <Jason_at_intel> so then 2) is all that is needed? and a fix to make 3) happen
18:29:36 <bdbaddog> should I push a new checkpoint asap since we keep getting complains about x64, and then another when these changes are done?
18:29:42 <Jason_at_intel> what about ia64
18:29:44 <cdavid> I have no support for itanium, though
18:30:04 <garyo> @bdbaddog: no, I think we're close, just wait til Thursday or Friday if that's OK w/ you.
18:30:07 <Jason_at_intel> ok not a big deal .. I have it for my stuff
18:30:09 <cdavid> bdbaddog: would next monday be good for a ck ?
18:30:15 <bdbaddog> sure.
18:30:17 <garyo> +1
18:30:28 <cdavid> The pb with itanium is that I cannot test it in any way
18:30:38 <cdavid> vmware does not support itanium :)
18:30:46 <Jason_at_intel> you can only test cross build for ia64
18:31:02 <garyo> ... but you can't run the result.
18:31:04 <cdavid> I can test it runs, not that it produces the right binary
18:31:18 <Jason_at_intel> with out a ia64 window system native case is hard to test .. I know ..
18:31:36 <cdavid> I wonder if wine supports ia - I guess not
18:31:37 <Jason_at_intel> agree... can test the runs
18:31:44 <Jason_at_intel> can't test :-)
18:31:53 <cdavid> wine can runs 64 bits command line binaries, now
18:31:58 <bdbaddog> I think it's a very small percentage of users using IA64.
18:32:07 <Jason_at_intel> well I would not want to emulate ia64
18:32:09 <garyo> OK, sounds like a plan. fix/test ASAP, checkpoint, then 2 wks to 1.3.
18:32:11 <bdbaddog> lets assume compiling is fine, and wait for bugs to prove otherwise..
18:32:13 <Jason_at_intel> ya very small
18:32:17 <Jason_at_intel> mostly cluster people
18:32:24 <bdbaddog> k.
18:32:34 <bdbaddog> I"m going to turn into a pumpkin in 5.
18:32:47 <garyo> send pix.
18:32:53 <stevenknight> this all sounds quite good
18:32:57 <bdbaddog> o.k. so I guess updates as to what progress on dev mailing list?
18:33:03 <cdavid> so gary, can you send me the patches ?
18:33:22 <garyo> yes, we'll all keep in touch. cdavid: tomorrow AM I hope. I have the right branch now :-)
18:33:51 <Jason_at_intel> I will update from trunk and run the Sconstruct from gary ( the one david made) and report out to you guys
18:34:06 <cdavid> Jason: the changes are in a git branch, not in svn for now
18:34:23 <Jason_at_intel> hmm does git work on windows?
18:34:24 <garyo> Jason: it's not on trunk, only David's git repo, and msvc_fixes branch in there.
18:34:39 <garyo> git works fine on Windows. Use msys git.
18:34:45 <bdbaddog> or cygwin git.
18:34:46 <Jason_at_intel> does git support a proxy servers?
18:34:47 <bdbaddog> ;)
18:34:51 <garyo> msys is better these days.
18:34:54 <bdbaddog> ahh.
18:34:57 <cdavid> yes, but throught http
18:35:03 <cdavid> better
18:35:05 <garyo> git can work via http or ssh.
18:35:07 <bdbaddog> o.k. I"m gone. Thanks to all!
18:35:08 <garyo> (or native)
18:35:13 <garyo> bye Bill!
18:35:17 <cdavid> I am removing some old stuff in github, and you can just grab a tarball
18:35:17 <bdbaddog> l8r
18:35:21 <Jason_at_intel> ok .. gary can you give me the link
18:35:23 <cdavid> bye Bill
18:35:28 * bdbaddog has quit ("[ChatZilla](ChatZilla) 0.9.85 [Firefox 3.5.4/20091016081620]")
18:35:29 <Jason_at_intel> in teh e-mail you will give me
18:35:33 <garyo> Will do, Jason.
18:35:36 <Jason_at_intel> thanks
18:36:03 <garyo> OK, thanks all! Good night.
18:36:11 <Jason_at_intel> night!
18:36:17 <stevenknight> great work guys, good night
18:36:26 <cdavid> [http://github.com/cournape/scons/archives/msvc_fixes](http://github.com/cournape/scons/archives/msvc_fixes)
18:36:34 <Jason_at_intel> oh one question
18:36:38 <garyo> ?
18:36:43 <Jason_at_intel> subst()
18:36:53 <Jason_at_intel> any idea when this will be addressed?
18:37:03 <Jason_at_intel> I am 90% sure this is why SCons is slow
18:37:06 <stevenknight> what part of it? how generally grungy it is?
18:37:07 <garyo> speed? functionality? quoting?
18:37:19 <Jason_at_intel> speed
18:37:29 <stevenknight> Jason_at_intel: re: 90%: kind of
18:37:42 <cdavid> Nodes are a big reason as well
18:37:48 <stevenknight> it's slow, but there are also algorithmic inefficiencies
18:37:57 <cdavid> depends on the projects, though
18:37:59 <stevenknight> we do a lot of string re-expansion multiple times
18:38:00 <Jason_at_intel> well there might be a node issues as well with speed
18:38:16 <Jason_at_intel> so the simple test is this
18:38:32 <cdavid> nodes cause memory pb and too many function calls, which are very slow in python
18:38:46 <Jason_at_intel> take 6000 node ( like read all the headers in Boost) and install them to a directory
18:38:52 <Jason_at_intel> take about 8 seconds
18:39:09 <Jason_at_intel> to process the env.Install()
18:39:16 <stevenknight> i have a half-finished prototype of a subst rewrite that uses the same general technique as the python string.Template class
18:39:21 <stevenknight> seems faster, but not benchmarked
18:39:29 <Jason_at_intel> remove the subst() call in [Arg2Node](Arg2Node).... 1 second
18:39:51 <garyo> !
18:39:59 <stevenknight> yow
18:40:28 <cdavid> and you lose nothing by not calling subsg in [Arg2Node](Arg2Node) ?
18:41:13 <Jason_at_intel> the builder has to turn the strings into nodes
18:41:31 <Jason_at_intel> the node creation in [Arg2Node](Arg2Node) does a subst of teh string value first
18:41:46 <garyo> In real life you do have to do a subst there, but if it could be super fast...
18:41:48 <Jason_at_intel> even if the string is fine.. nothing to do, this takes time
18:42:14 <stevenknight> or if we can avoid work if it doesn't need subst()
18:42:25 <stevenknight> subst() itself checks for '$' in the string and just returns
18:42:26 <stevenknight> but
18:42:47 <stevenknight> Jason_at_intel's pointing out there's a bunch of work in Env.py before we even call subst()
18:43:03 <stevenknight> i wonder how much time gets saved if we move the '$' check
18:43:24 <Jason_at_intel> ya there is a lot of work in env... but it does not seem to be the critical path
18:43:42 <Jason_at_intel> in fact to help with speed issues.. if we can get this Scons to work in iron python
18:43:59 <Jason_at_intel> I can give you very detailed data on what is the performance issues
18:44:18 <stevenknight> ? env isn't critical path? that's where arg2nodes() lives
18:44:20 <garyo> but wait, stay on topic. You remove the subst, it drops the time from 8 to 1 sec.
18:44:21 <Jason_at_intel> as I can use our tools on .net code..
18:44:43 <garyo> So where's the time going if subst() shortcuts when there's no $?
18:44:44 <Jason_at_intel> ya... arg2node is a big fish.. not it slow because of subst
18:45:07 <stevenknight> ? okay, you're really confusing me
18:45:08 <garyo> OK, good -- figure out which part of arg2node is causing the slowdown.
18:45:21 <stevenknight> you say if you remove the subst() call from arg2nodes() you get an 87.5% speedup
18:45:31 <Jason_at_intel> So when i tested this for a few days it was teh subst
18:45:34 <stevenknight> then you tell me that arg2nodes() is not slow because of subst()
18:45:46 <stevenknight> which is it?
18:46:09 <Jason_at_intel> I made sure the string i had where fully subst'ed before arg2node
18:46:20 <cdavid> By everone - I will work on updating scons in the meantime
18:46:26 <Jason_at_intel> the simple find was that something in the subst call itself is slow
18:46:29 <stevenknight> so your speedup wasn't removing subst() from arg2nodes()
18:46:35 <stevenknight> ?
18:46:48 <Jason_at_intel> so yes.. i did three basic tests
18:46:55 <Jason_at_intel> 1) my base line
18:47:05 <Jason_at_intel> 2) with string fully substed
18:47:20 <Jason_at_intel> 3) with subst in arg2node commented out
18:47:42 <Jason_at_intel> 1) 2) 8,6 seconds
18:47:51 <Jason_at_intel> 3) 1 ish
18:48:59 <garyo> Well that's pretty clear.
18:49:01 <Jason_at_intel> I could not find anything else that seemed to have such a large effect on the read time of the SConstruct as of yet
18:49:32 <garyo> So it must be that subst() isn't just returning... or the strings are really long and just searching for the $ is costly?
18:49:41 <stevenknight> no, there are two layers to subst
18:49:50 <stevenknight> there's the env.subst() wrapper that does a bunch of set up
18:49:51 <Jason_at_intel> I have not looked to what in subst is teh issue.. everyone at work wants to me to fix the sdk feature in Parts and speed up the build by not tell SCons stuff
18:50:08 <stevenknight> and there's the Subst.scons_subst() function that does the heavy lifting
18:50:33 <stevenknight> the Subst.scons_subst() function will look for a '$' and return if everything's expanded
18:50:46 <stevenknight> but that's *after* the env.subst() wrapper has done a bunch of set up
18:50:53 <stevenknight> originally, that was a thin layer
18:50:57 <stevenknight> but it's grown over time
18:51:35 <stevenknight> based on what Jason_at_intel's found, I bet if we move the '$' check into the env.subst() wrapper we get a huge win
18:51:51 <Jason_at_intel> I can give it a try
18:52:18 <Jason_at_intel> even after that it would be nice to speed up subst as i use it a lot in Parts
18:52:24 <stevenknight> yeah
18:52:40 <Jason_at_intel> I would rather not have to add more code to do it before
18:52:49 <stevenknight> i think the prototype i half-finished is promising
18:53:00 <stevenknight> but when i stepped back and tried to redo things fresh
18:53:13 <stevenknight> the big hassle is actually subst_list()
18:53:34 <Jason_at_intel> so i will see about reporting out number in the next day with scons 1.2 and hacking up the env.subst to look for $ in the string first
18:53:52 <stevenknight> our current rules for when something does or doesn't get expanded into separate arguments in a list are really arbitrary
18:54:10 <stevenknight> cool
18:54:28 <Jason_at_intel> ya honestly in parts i have my own code for this
18:54:46 <Jason_at_intel> the subst and return a list logic was odd for me
18:54:52 <Jason_at_intel> code not figure it out
18:54:57 <stevenknight> "odd" is putting it kindly
18:55:22 <Jason_at_intel> well I am trying to be postive
18:55:25 <Jason_at_intel> :-)
18:55:37 <stevenknight> much appreciated... :-)
18:56:46 <Jason_at_intel> anyways the speed items for me seem to be fixable by having better subst calls, faster disks ( when scanning for files) and in our case of a large project not reading data to components that don't nee to be built
18:56:58 <Jason_at_intel> nee->need
18:57:42 <Jason_at_intel> I think the node code coudl be a little better in the creation for the global file list
18:58:00 <Jason_at_intel> but that does not seem to be a big fish in speed so far
18:58:26 <Jason_at_intel> we have about 100,000 source files being process and copied in our builds
18:58:45 <stevenknight> we need a performance-testing infrastructure in the buildbots
18:59:16 <stevenknight> something that makes it easy to add tests like your 6000 node config
18:59:20 <Jason_at_intel> the only issue after read stage i have seen is that the task master takes a longer time if one node is to be rebuilt
18:59:21 <stevenknight> time and graph the results
18:59:51 <Jason_at_intel> I will try to send you a test sample based on boost
19:00:19 <stevenknight> okay, i need to finish
19:00:23 <Jason_at_intel> ok
19:00:34 <stevenknight> i'll send you guys some off-line thoughts about some things
19:00:36 <stevenknight> 'night
19:00:45 <Jason_at_intel> well I will try to give out some data on msvc for gary and give you stuff about subst by end of week
19:01:00 <Jason_at_intel> later!
19:03:16 * Jason_at_intel has quit ("[ChatZilla](ChatZilla) 0.9.85 [Firefox 3.5.3/20090824101458]")
20:00:33 * garyo has quit ("Leaving.")
23:49:41 * cdavid has quit ("Page closed")