1. SCons
  2. Core
  3. SCons

Wiki

Clone wiki

SCons / BugParty / IrcLog2009-11-03

16:19:19  *      garyo (n=[garyo@209-6-158-38.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com](mailto:garyo@209-6-158-38.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com)) has joined #scons 
16:44:41  *      Jason_at_intel (n=[chatzill@12.18.240.224](mailto:chatzill@12.18.240.224)) has joined #scons 
16:48:34  *      bdbaddog (n=[chatzill@adsl-71-142-94-71.dsl.pltn13.pacbell.net](mailto:chatzill@adsl-71-142-94-71.dsl.pltn13.pacbell.net)) 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=[knight@c-67-164-61-68.hsd1.ca.comcast.net](mailto:knight@c-67-164-61-68.hsd1.ca.comcast.net)) 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") 

Updated