Please note:The SCons wiki is now restored from the attack in March 2013. All old passwords have been invalidated. Please reset your password if you have an account. If you note missing pages, please report them to webmaster@scons.org. Also, new account creation is currently disabled due to an ongoing spam flood (2013/08/27).
   1 16:19:19 *	garyo (n=garyo@209-6-158-38.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has joined #scons
   2 16:44:41 *	Jason_at_intel (n=chatzill@12.18.240.224) has joined #scons
   3 16:48:34 *	bdbaddog (n=chatzill@adsl-71-142-94-71.dsl.pltn13.pacbell.net) has joined #scons
   4 16:58:21 <Jason_at_intel>	so Gary question
   5 16:58:26 <garyo>	yes?
   6 16:58:30 <Jason_at_intel>	the scons site stuff
   7 16:58:38 <Jason_at_intel>	is this planned for after 1.3?
   8 16:59:00 <Jason_at_intel>	2.0?
   9 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.
  10 16:59:15 <garyo>	Bill, what do you think?
  11 17:00:17 <bdbaddog>	how long til u think it'd be ready?
  12 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?"
  13 17:00:37 <garyo>	I could do it in a (long) night, really.
  14 17:00:45 <garyo>	Testing would take longer.
  15 17:01:19 <garyo>	The Windows dir-searching stuff is most of the work, but there's some code in the SEP already...
  16 17:01:35 <bdbaddog>	URL?
  17 17:01:53 <garyo>	MoreSiteSConsDirs in the wiki.
  18 17:02:14 <Jason_at_intel>	on the discussion page of this area is code for it
  19 17:02:19 <garyo>	(sorry, typing on one machine w/ spreadsheet etc. open in the other one, it's confusing)
  20 17:02:32 <garyo>	yes, Jason contributed a bunch of it.
  21 17:02:09 *	GregNoel is no longer marked as being away
  22 17:02:49 <GregNoel>	Hey, ho
  23 17:03:06 <Jason_at_intel>	Hi Greg!
  24 17:03:42 <GregNoel>	I'm a little under the weather; please excuse any slow typing tonight.
  25 17:03:06 <garyo>	btw, speaking of the wiki, you're all supposed to subscribe to the BugParty page so you get an email when it gets updated.  Hi Greg!
  26 17:03:38 <garyo>	Shall we get going?  We clearly have a quorum.
  27 17:03:52 <GregNoel>	yes, start
  28 17:03:59 <garyo>	Jason, Bill, Gary, Greg, who'd I miss?
  29 17:04:14 <bdbaddog>	o.k. I'm subscribed to the page now.
  30 17:04:19 <garyo>	thx
  31 17:04:21 <bdbaddog>	Didn't know u could do that.. doh..
  32 17:04:25 <Jason_at_intel>	same..
  33 17:04:31 *	cdavid (i=82360a48@gateway/web/freenode/x-6ed6991a2ed30d5c) has joined #scons
  34 17:04:34 <garyo>	cool.
  35 17:04:48 <garyo>	Shall we dive into the bugs?  It's been almost 3 months.
  36 17:04:48 <GregNoel>	2427
  37 17:04:51 <Jason_at_intel>	Hi David!
  38 17:04:57 <cdavid>	Hi everyone
  39 17:05:04 <cdavid>	hope I am on time
  40 17:05:05 <garyo>	Hi David.
  41 17:05:06 <bdbaddog>	4 time zones now represented :)
  42 17:05:15 <garyo>	:-)
  43 17:05:29 <Jason_at_intel>	5 people?
  44 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.
  45 17:05:55 <GregNoel>	2427, we agreed to document it, but didn't decide when
  46 17:06:07 <bdbaddog>	anytime?
  47 17:06:08 <garyo>	So let's doc 2427 ASAP.
  48 17:06:12 <garyo>	sure, anytime.
  49 17:06:29 <GregNoel>	OK, who?  and priority?
  50 17:06:44 <bdbaddog>	I'll take it.
  51 17:06:48 <garyo>	thanks!
  52 17:06:52 <GregNoel>	priority?
  53 17:07:03 <garyo>	p3?
  54 17:07:09 <GregNoel>	worksforme
  55 17:07:31 <GregNoel>	2443
  56 17:08:25 <bdbaddog>	is this taskman stuff?
  57 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.
  58 17:08:56 <GregNoel>	No, Steven thought it was OK.
  59 17:09:02 <garyo>	(ok, sorry)
  60 17:09:33 <GregNoel>	There are two subst_list()s in different places.
  61 17:09:14 <garyo>	I say too late for 1.3, but p1 or p2 for 2.0.
  62 17:09:21 <garyo>	Steven or me.
  63 17:09:24 <Jason_at_intel>	honestly in Part i use action in Aliases a bit.. would break if they did not work
  64 17:10:21 <GregNoel>	2.0 p2/3 garyo since Steven is so busy
  65 17:10:25 <garyo>	well his 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.
  66 17:10:29 <garyo>	OK w/ me.
  67 17:10:35 <bdbaddog>	+1
  68 17:10:48 <GregNoel>	done
  69 17:10:52 <GregNoel>	2444
  70 17:11:11 <garyo>	anytime, p4?
  71 17:11:18 <GregNoel>	ok, who?
  72 17:12:01 <bdbaddog>	I'll take it. Got one doc bug, another won't be much more pain.
  73 17:12:06 <GregNoel>	done
  74 17:12:11 <GregNoel>	2445
  75 17:12:44 <garyo>	bug's invalid, but left there for python minversion discussion, right?
  76 17:12:57 <GregNoel>	I've fixed a couple and I have one queued up.
  77 17:13:10 <bdbaddog>	yes.  So let's stick logic in to check 1.5.2 < current version < 3.0 ?
  78 17:13:28 <garyo>	That sounds simple enough.
  79 17:13:44 <GregNoel>	Er, 2.4 < ver < 3.0
  80 17:13:47 <bdbaddog>	we have the deprecation and such logic there already so shouldnt' be too bad. go ahead an assign to me.
  81 17:13:59 <bdbaddog>	for 1.3 , 1.5.2 < curr < 3.0, for 2.0 as you said.
  82 17:14:17 <GregNoel>	1.3 p(what?)
  83 17:14:29 <garyo>	Yes.  Bill, you have time to stick that check in soonish?
  84 17:14:35 <bdbaddog>	yes.
  85 17:14:43 <garyo>	+1
  86 17:14:58 <GregNoel>	p2 then? or p1?
  87 17:15:04 <garyo>	p2
  88 17:15:07 <bdbaddog>	plus 2.0 might take a bit to get out and 3.0, 3.1 will become more common.
  89 17:15:11 <bdbaddog>	p1.
  90 17:15:18 <garyo>	your call.
  91 17:15:26 <GregNoel>	p1, done
  92 17:15:28 *	jesterKing is now known as amino
  93 17:15:35 <GregNoel>	2446
  94 17:16:07 <GregNoel>	only two comments; skip
  95 17:16:12 <GregNoel>	2447
  96 17:16:23 <GregNoel>	only two comments; skip
  97 17:16:35 <GregNoel>	2448
  98 17:17:06 <bdbaddog>	2.x ?
  99 17:17:07 <garyo>	3.x p3 unless Ken has a patch.
 100 17:17:21 <bdbaddog>	3.x is fine. we could pull in if a patch appears.
 101 17:17:24 <GregNoel>	agree w/ gary
 102 17:17:25 <garyo>	(Bill, I'd love to have it earlier, but who would do it?)
 103 17:17:54 <bdbaddog>	I'm fine with 3.x
 104 17:17:47 <GregNoel>	I'll put ken on it; anybody want CC?
 105 17:18:05 <bdbaddog>	CC ?
 106 17:18:10 <bdbaddog>	cc on the bug?
 107 17:18:15 <GregNoel>	yes
 108 17:18:24 <Jason_at_intel>	yes
 109 17:18:29 <bdbaddog>	yes
 110 17:18:39 <GregNoel>	done
 111 17:18:45 <GregNoel>	1449
 112 17:18:56 <garyo>	2449 :-)
 113 17:19:11 <GregNoel>	oops, yes
 114 17:19:13 <cdavid>	can we use subprocess ? I am a bit confused by the version requirements of scons
 115 17:19:30 <bdbaddog>	1.5.2 < current version < 3.0 for 1.3
 116 17:19:35 <Jason_at_intel>	2.4 subprocess should be good
 117 17:19:41 <bdbaddog>	2.4 < current version < 3.0 for 2.0
 118 17:19:42 <cdavid>	so we cannot use subprocess ?
 119 17:19:46 <cdavid>	for 1.3
 120 17:19:47 <bdbaddog>	nope. not for 1.3
 121 17:19:48 <Jason_at_intel>	plus we can remove the open() hack on teh win32 platform
 122 17:19:49 <GregNoel>	Subprocess is not the issue; we already have a backward-compatible version we're using now.
 123 17:19:55 <Jason_at_intel>	fixes issues on win7
 124 17:19:59 <garyo>	but we start working on 2.0 as soon as 1.3 is out the door
 125 17:20:13 <bdbaddog>	yes. 2.0/2.x for 2449
 126 17:20:44 <GregNoel>	not 2.0; that's only bug fixes and removing backward compatibility.
 127 17:21:02 <bdbaddog>	isn't this a bug fix?
 128 17:21:15 <Jason_at_intel>	agree
 129 17:21:16 <GregNoel>	No, it's an issue
 130 17:22:23 <GregNoel>	I should have said *trivial* bug fixes, as in fixes to documentation.
 131 17:21:36 <Jason_at_intel>	is it not.. since you have a subprocess copy in SCons
 132 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.
 133 17:21:39 <GregNoel>	Yes, that's the intent.
 134 17:21:40 <bdbaddog>	-j sometimes breaks on windows seems like a bug.
 135 17:21:51 <Jason_at_intel>	I woudl think we would rather use the Scons version if we could
 136 17:21:53 <bdbaddog>	how hard to swap to subprocess ?
 137 17:22:10 <bdbaddog>	2.1 then?
 138 17:22:11 <Jason_at_intel>	it easy.. it the SPAWN functions
 139 17:23:04 <GregNoel>	If it were that easy, we'd have done it already.  It's not.
 140 17:22:51 <bdbaddog>	lets mark it 2.x, and hold on the waht goes into 2.0 discussion?
 141 17:23:22 <Jason_at_intel>	no.. you have not moved to Python 2.4 as a base requiremnet
 142 17:23:27 <bdbaddog>	I though we were precluded because of 1.5.2 compat requirement
 143 17:23:31 <Jason_at_intel>	in Parts we require 2.5 or better
 144 17:23:51 <Jason_at_intel>	we use Subprocess via replacing SPAWN with our version
 145 17:23:51 <bdbaddog>	Let's mark it 2.x and move on?
 146 17:24:03 <bdbaddog>	we can pull it in if it's easy.
 147 17:24:04 <Jason_at_intel>	it works great.. we even colorize output now
 148 17:24:20 <GregNoel>	Seeing no consensus, consider next time
 149 17:24:34 <Jason_at_intel>	wait till 2.0 .. it will not hurt
 150 17:24:49 <garyo>	Greg, let's mark it 2.x and move on.
 151 17:24:58 <bdbaddog>	+1 2.x
 152 17:25:07 <GregNoel>	garyo, what priority?
 153 17:25:16 <bdbaddog>	p2
 154 17:25:16 <garyo>	p1 or p2, it's big.
 155 17:25:19 <bdbaddog>	p1
 156 17:25:20 <garyo>	ok, p2
 157 17:25:23 <bdbaddog>	p2
 158 17:25:25 <garyo>	ok, p1
 159 17:25:29 <garyo>	:-)
 160 17:25:36 <bdbaddog>	ok p1.
 161 17:25:40 <GregNoel>	p1 is for emergencies; p2
 162 17:25:44 <bdbaddog>	p2
 163 17:25:46 <garyo>	fine
 164 17:25:49 <bdbaddog>	fine
 165 17:26:07 <GregNoel>	who?
 166 17:26:17 <garyo>	Jason, could you try it?
 167 17:26:17 <bdbaddog>	Jason?
 168 17:26:30 <GregNoel>	or make it part of the 2.x discussion?
 169 17:26:36 <Jason_at_intel>	is  this 2449
 170 17:26:42 <bdbaddog>	yup
 171 17:26:45 <cdavid>	I could also look at it - I think I have tried using subprocess in scons
 172 17:26:49 <Jason_at_intel>	I can give you a patch
 173 17:27:01 <cdavid>	and I use -j option quite a bit on windows nowadays
 174 17:27:04 <garyo>	ok, David w/ jason as cc?
 175 17:27:14 <GregNoel>	yes, sounds good
 176 17:27:18 <bdbaddog>	+1
 177 17:27:19 <GregNoel>	done
 178 17:27:26 <GregNoel>	2450
 179 17:28:05 <garyo>	I like this one.
 180 17:28:31 <garyo>	I think we should just put it in in 2.x.  I'll do it.
 181 17:28:36 <bdbaddog>	+1
 182 17:28:41 <GregNoel>	I think it's badly entangled with 2446 and 2447, but if you want it, go for it.
 183 17:28:45 <GregNoel>	what priority?
 184 17:28:49 *	stevenknight (n=knight@c-67-164-61-68.hsd1.ca.comcast.net) has joined #scons
 185 17:28:52 <garyo>	I don't think it's that tangled.
 186 17:28:54 <bdbaddog>	p3 or p4 ?
 187 17:28:58 <garyo>	Hi Steven!!!
 188 17:29:02 <Jason_at_intel>	Hi steve
 189 17:29:06 <stevenknight>	hey guys
 190 17:29:11 <garyo>	How are you?
 191 17:29:15 <GregNoel>	Steven, we're considering 2450
 192 17:29:17 <Jason_at_intel>	long time no see!
 193 17:29:19 <stevenknight>	been better
 194 17:29:22 <stevenknight>	yeah
 195 17:29:29 <stevenknight>	sick kid *and* a sick laptop today
 196 17:29:35 <garyo>	:(
 197 17:29:47 <bdbaddog>	hmm. laptop got H1n1 ?
 198 17:30:35 <stevenknight>	bdbaddog:  maybe, google remote tech support was stymied
 199 17:30:43 <stevenknight>	let me get caught up with you all
 200 17:30:52 <stevenknight>	(don't wait, though)
 201 17:31:16 <cdavid>	hi steven
 202 17:29:01 <garyo>	p3's fine.
 203 17:30:15 <GregNoel>	what priority?
 204 17:30:21 <GregNoel>	p3?
 205 17:30:24 <garyo>	2450? p3.
 206 17:30:28 <Jason_at_intel>	p3?
 207 17:30:26 <GregNoel>	done
 208 17:30:35 <GregNoel>	2451
 209 17:31:23 <GregNoel>	Gary, you're the expert on this one
 210 17:31:18 <Jason_at_intel>	so Gary did you think this was doable in 1.3
 211 17:31:28 <Jason_at_intel>	at least an early drop of it?
 212 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.
 213 17:32:04 <GregNoel>	Uh, I'd resist 1.3; already too delayed.
 214 17:32:07 <garyo>	I guess I don't feel that strongly about the module/package thing.
 215 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.
 216 17:32:47 <bdbaddog>	so "anytime"
 217 17:32:54 <Jason_at_intel>	good for me
 218 17:32:57 <garyo>	I guess that's right.
 219 17:33:04 <bdbaddog>	+1
 220 17:33:16 <stevenknight>	hey cdavid
 221 17:33:19 <GregNoel>	I don't like possibly destabilizing 1.3; 2.1?
 222 17:33:31 <garyo>	We
 223 17:33:35 <garyo>	(sorry)
 224 17:34:02 <GregNoel>	(and here I thought you were talking about my new Wii)
 225 17:34:01 <bdbaddog>	anytime pending code review into 1.3? otherwise 2.1?
 226 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?
 227 17:34:09 <stevenknight>	at this point, i'd think 1.3 should be cut to bare minimum
 228 17:34:38 <GregNoel>	concur with stevenknight
 229 17:34:14 <cdavid>	what are the big things for 1.3 ? Just releasing what's out there in the trunk ?
 230 17:34:20 <cdavid>	I mean the goal of 1.3.0 ?
 231 17:34:30 <garyo>	msvc!
 232 17:34:36 <bdbaddog>	let's punt til 5:50 for 1.3 discussion?
 233 17:34:37 <cdavid>	ok
 234 17:35:03 <garyo>	OK, I'll hold back on the site_scons stuff.  No prob.
 235 17:35:14 <Jason_at_intel>	2.x then
 236 17:35:30 <garyo>	Yes, probably early like 2.1.
 237 17:35:32 <GregNoel>	consensus?  2.1?  what priority?
 238 17:35:37 <bdbaddog>	2.1 p3 ?
 239 17:35:40 <garyo>	p3
 240 17:35:44 <stevenknight>	2.1 p3
 241 17:35:44 <GregNoel>	done
 242 17:36:00 <GregNoel>	2452
 243 17:36:38 <bdbaddog>	future p1 for 2452
 244 17:36:50 <cdavid>	if 2.0 should only do backward incompatible changes, this would be 3.x ?
 245 17:37:10 <bdbaddog>	there's 2.x
 246 17:37:17 <bdbaddog>	and 2.1
 247 17:37:23 <GregNoel>	I'd like to assign Ludwig, but suggest very strongly that he work with Ken, since they have complementary insights on this
 248 17:37:24 <garyo>	right.
 249 17:37:34 <bdbaddog>	+1
 250 17:37:38 <garyo>	+1
 251 17:37:52 <stevenknight>	+1 and I'll raise another +1
 252 17:38:06 <Jason_at_intel>	so when is 3.x?
 253 17:38:07 <GregNoel>	Not 3.x; it's all internal, no user API affected
 254 17:38:29 <Jason_at_intel>	I agree with that
 255 17:38:42 <Jason_at_intel>	seen like a 2.x thing
 256 17:38:46 <bdbaddog>	so 2.x then or future? depends when we have a solution.
 257 17:38:56 <bdbaddog>	+1 2.x p1
 258 17:39:03 <Jason_at_intel>	+1
 259 17:39:07 <stevenknight>	2.x p1
 260 17:39:08 <GregNoel>	2198 already has a patch, but I want Ken to refine it.
 261 17:39:31 <garyo>	ok, maybe he can roll them all together.
 262 17:39:39 <GregNoel>	2.x p2, it's not an emergency
 263 17:39:48 <garyo>	agreed.
 264 17:40:11 <stevenknight>	good point
 265 17:39:49 <bdbaddog>	+1 p2
 266 17:40:15 <GregNoel>	done
 267 17:40:23 <GregNoel>	2453
 268 17:40:40 <bdbaddog>	2.x p3
 269 17:40:54 <garyo>	ok w/ me
 270 17:41:11 <garyo>	Ludwig/Ken or Ken/Ludwig :-/
 271 17:41:37 <GregNoel>	Ludwig/Ken; I have confidence that Ludwig will close it.
 272 17:42:10 <GregNoel>	No other objections?  Done 2.x p3 Ludwig
 273 17:42:16 <GregNoel>	2454
 274 17:42:32 <garyo>	Ken should just do this.  It's easy.
 275 17:42:42 <garyo>	"Please submit a patch."
 276 17:42:47 <GregNoel>	Same stuff, same comments from me
 277 17:42:55 <bdbaddog>	2.x p3 then?
 278 17:42:59 <garyo>	2.x p3 Ken?
 279 17:43:07 <stevenknight>	sounds good
 280 17:43:09 <GregNoel>	I'd go with Ludwig
 281 17:43:15 <garyo>	(at least Ken to submit the patch?)
 282 17:43:22 <GregNoel>	I'll buy that
 283 17:43:31 <bdbaddog>	+1
 284 17:43:34 <stevenknight>	+1
 285 17:43:37 <GregNoel>	done
 286 17:43:43 <GregNoel>	2455
 287 17:44:13 <GregNoel>	Looks like consensus research garyo
 288 17:44:18 <GregNoel>	what priority?
 289 17:44:20 <garyo>	OK.
 290 17:44:28 <garyo>	p3 or p4
 291 17:44:38 <bdbaddog>	p4
 292 17:44:40 <cdavid>	this would better be done at the same time as fixing configure IMO
 293 17:44:41 <stevenknight>	p4 if either is ok
 294 17:44:51 <GregNoel>	p4
 295 17:44:52 <GregNoel>	done
 296 17:44:59 <GregNoel>	2455
 297 17:45:01 <garyo>	cdavid: what other configure fixes are related?
 298 17:45:54 <cdavid>	configure does not use the same process as normal scons, so everytime you change your configure context, scons is confused
 299 17:45:54 <garyo>	anyway I think this particular issue is easily solved.
 300 17:46:26 <stevenknight>	cdavid:  agree, but that'll take a while to fix
 301 17:46:39 <bdbaddog>	so research, garyo, p4 ?
 302 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.
 303 17:46:44 <GregNoel>	I agree with cdavid that fixing configure would fix this, but it needs to be solved sooner.
 304 17:46:56 <stevenknight>	research garyo p4
 305 17:46:57 <cdavid>	yes, it will take time, but fixing confdefs without fixing configure seems wasteful
 306 17:46:57 <garyo>	bdbaddog: +1
 307 17:47:25 <garyo>	cdavid: nah, it's just a missing string assignment somewhere or something like that.
 308 17:47:44 <garyo>	It's not like configure isn't useful as it is, a lot of people use it.
 309 17:47:48 <GregNoel>	p4
 310 17:48:04 <cdavid>	ah, sorry, I thought it required adding a new arg to CheckHeader, I was confused by the different use cases on the wiki
 311 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.
 312 17:48:05 <garyo>	2456: done.
 313 17:48:11 <stevenknight>	2457
 314 17:48:24 <bdbaddog>	2.x p3, me
 315 17:48:38 <stevenknight>	I like russel's suggestion, make it qt3 with qt as a backwards compatible alias?
 316 17:48:52 <bdbaddog>	+1 alias, with deprecation notice?
 317 17:48:58 <stevenknight>	yeah
 318 17:49:03 <GregNoel>	concur
 319 17:49:02 <bdbaddog>	most all new qt work will be qt4
 320 17:49:39 <bdbaddog>	I'm hoping qt40,41,42,43,45 won't be necessary
 321 17:49:42 <GregNoel>	2.x p3 bdbaddog?
 322 17:49:46 <bdbaddog>	+1
 323 17:49:51 <stevenknight>	done
 324 17:49:56 <GregNoel>	done
 325 17:50:06 <GregNoel>	2458
 326 17:50:34 <garyo>	invalid.
 327 17:50:55 <garyo>	can say: "sorry, we can't change it at this point."
 328 17:50:58 <GregNoel>	invalid
 329 17:51:07 <bdbaddog>	invalid, though once we rationalize tools/platofrms.. we might be able to handle better.
 330 17:51:07 <stevenknight>	i can live with that
 331 17:51:11 <GregNoel>	"and wait for new configure"
 332 17:51:18 <Jason_at_intel>	these can be overridden
 333 17:51:26 <stevenknight>	note added to doc, though?
 334 17:51:40 <stevenknight>	seems like potentially a common enough stumbling point
 335 17:51:50 <garyo>	not a bad idea.
 336 17:51:45 <GregNoel>	who, when?
 337 17:51:59 <garyo>	Bill, since you're doc guy today... ?
 338 17:52:06 <bdbaddog>	+1 doc, all we have to say is add -fwin32 for win32 right?
 339 17:52:16 <stevenknight>	believe so
 340 17:52:13 <bdbaddog>	yup. sign me up.
 341 17:52:16 <GregNoel>	could be 1.3 or 2.0
 342 17:52:22 <GregNoel>	if it's only doc
 343 17:52:25 <bdbaddog>	so anytime.
 344 17:52:35 <bdbaddog>	so anytime, p3, Bill
 345 17:52:39 <GregNoel>	done
 346 17:53:01 <bdbaddog>	how much more time does everyone have?
 347 17:53:17 <garyo>	I don't have to go anytime soon.
 348 17:53:17 <bdbaddog>	wanted to talke for 10 minutes about 1.3 before we all head off.
 349 17:53:23 <Jason_at_intel>	I am good
 350 17:53:41 <GregNoel>	I've got maybe 30 more minutes
 351 17:53:57 <stevenknight>	i'm okay for a while
 352 17:53:58 <bdbaddog>	ok. let's go mabye 10 more on bugs and then talke about 1.3 ?
 353 17:54:00 <garyo>	ok, let's stop at 10 after and talk about 1.3
 354 17:54:02 <GregNoel>	I'd like to finish these if possible
 355 17:54:03 <bdbaddog>	+1
 356 17:54:13 <stevenknight>	(positive side to laptop dying:  i can't do any day-job work...  :-))
 357 17:54:16 <cdavid>	fine by me
 358 17:52:51 <GregNoel>	2459
 359 17:52:59 <garyo>	invalid, imho.
 360 17:53:24 <GregNoel>	invalid
 361 17:53:37 <bdbaddog>	+1 invalid
 362 17:54:58 <Jason_at_intel>	2459 seem invalid to me
 363 17:53:53 <GregNoel>	done
 364 17:54:55 <GregNoel>	2460
 365 17:55:30 <bdbaddog>	2460, 2.x, who, p2 ?
 366 17:56:06 <Jason_at_intel>	I agree that i would rather have Depends work with Alias.. not alias another alias
 367 17:56:35 <garyo>	Sure, Depends should work, but this kind of stuff can get complicated.  If Steven could do it...
 368 17:56:39 <Jason_at_intel>	this seems to be a node issue.. who does the node code?
 369 17:57:37 <garyo>	I think it'd have to be Steven, or else 3.x when someone else may have time/knowledge.
 370 17:57:45 <GregNoel>	concur
 371 17:57:50 <garyo>	So that's why I said 3.x p3.
 372 17:57:52 <Jason_at_intel>	+1
 373 17:57:56 <bdbaddog>	+1
 374 17:58:04 <stevenknight>	go ahead and put my name on it
 375 17:58:03 <GregNoel>	done
 376 17:58:32 <stevenknight>	i'm going to go through my issues and re-prioritize, give back ones that others can do
 377 17:59:04 <garyo>	steven: ok, make a list of what needs to be re-triaged.
 378 17:59:18 <stevenknight>	garyo:  will do
 379 17:58:32 <bdbaddog>	2461, invalide
 380 17:58:32 <garyo>	2461 looks invalid.
 381 17:58:37 <GregNoel>	done
 382 17:59:07 <GregNoel>	2462
 383 17:59:18 <cdavid>	I can reproduce 2462
 384 17:59:45 <cdavid>	but in a big project only - I can try to make a small reproducible script to track it down
 385 17:59:29 <bdbaddog>	2.1,p1, who?
 386 17:59:49 <garyo>	cdavid: me too.  I'll take it, I fixed another one like it once.
 387 17:59:54 <cdavid>	ok
 388 18:00:02 <Jason_at_intel>	I have not seen this yet
 389 18:00:23 <garyo>	Happens when you rename or delete things and the .sconsign has a ref to them, typically.
 390 18:00:36 <garyo>	... and if Glob is involved it's more likely.
 391 18:00:52 <Jason_at_intel>	ahh we don't use GLob
 392 18:00:34 <GregNoel>	garyo with cdavid as CC?  2.1, p1
 393 18:00:38 <GregNoel>	er, p2
 394 18:00:44 <garyo>	p2, thanks.
 395 18:00:50 <cdavid>	fine by me
 396 18:00:51 <bdbaddog>	2.1, p2, garyo ?
 397 18:01:00 <Jason_at_intel>	+1
 398 18:01:01 <GregNoel>	done
 399 18:01:08 <GregNoel>	2463
 400 18:01:27 <bdbaddog>	2.x, garyo, p3 ?
 401 18:01:29 <garyo>	I'll remove it in 2.x (or even 2.1).
 402 18:01:31 <GregNoel>	2.x p3 garyo
 403 18:01:51 <GregNoel>	do you want 2.1 or 2.x?
 404 18:02:09 <garyo>	2.1.
 405 18:02:11 <GregNoel>	done
 406 18:02:20 <GregNoel>	2465
 407 18:02:37 <bdbaddog>	1.3,me, p2 or p3
 408 18:02:50 <garyo>	I'm ok w/ 1.3 since it's only bootstrap.py.
 409 18:03:00 <GregNoel>	OK, done
 410 18:03:14 <garyo>	woo hoo!
 411 18:03:21 <GregNoel>	and now for the 1.3 discussion...
 412 18:03:28 <bdbaddog>	:D
 413 18:03:40 <bdbaddog>	o.k. what's left? how much msvc stuff?
 414 18:04:04 <garyo>	I think we should seriously consider David's simplifications.
 415 18:04:04 <Jason_at_intel>	what are the issues?
 416 18:04:05 <cdavid>	there is the "how to deal with error" stuff
 417 18:04:13 <Jason_at_intel>	1)cross build
 418 18:04:17 <Jason_at_intel>	2) SDK?
 419 18:04:18 <garyo>	... with a bit of error handling.
 420 18:04:26 <garyo>	Ah yes, SDK.
 421 18:04:31 <cdavid>	cross build works for me
 422 18:04:40 <cdavid>	SDK is much more difficult
 423 18:04:48 <garyo>	Cross build should work for me, but I have a test-machine issue. :-/
 424 18:04:55 <garyo>	(w/ David's version)
 425 18:05:02 <Jason_at_intel>	I view SDK as have the users add it to tools they load
 426 18:05:14 <garyo>	+1, make users add it.
 427 18:05:14 <Jason_at_intel>	once we get toolchains then it will be easier
 428 18:05:15 <cdavid>	that would make the problem go away :)
 429 18:05:28 <cdavid>	ok, so don't handle sdk automatically
 430 18:05:39 <Jason_at_intel>	yes, let the user add it
 431 18:05:42 <cdavid>	what's the best way to print a user warning ?
 432 18:05:44 <garyo>	Does setting MSSDK_VERSION do it?
 433 18:06:01 <Jason_at_intel>	this way they can control is it add it stuff before or after the compiler lines
 434 18:06:06 <cdavid>	no, you would have to use the mssdk tool
 435 18:06:25 <garyo>	cdavid: oh yeah.  That's fine.
 436 18:06:26 <cdavid>	so MSSDK_VERSION would control it, but you would have to explicitly load the mssdk tool
 437 18:06:26 <Jason_at_intel>	MSSDK_VERSION set which version you setup
 438 18:06:46 <garyo>	Needs to be documented
 439 18:07:02 <cdavid>	ah, I forgot about msvs
 440 18:07:12 <cdavid>	what's the need for MSVS_VERSION and MSVC_VERSION ?
 441 18:07:14 <Jason_at_intel>	so mssdk issue
 442 18:07:19 <Jason_at_intel>	agreeded?
 443 18:07:23 <cdavid>	agreed
 444 18:07:26 <garyo>	Jason: yes.
 445 18:07:52 <cdavid>	in the trunk, both vs and vc code look for a batch file
 446 18:08:03 <cdavid>	I don't know the rationale for this - I don't do it in the cleaned up branch
 447 18:08:05 <garyo>	cdavid: I always thought MSVS_VERSION was for making Visual Studio projects, but I don't really know.
 448 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
 449 18:08:27 <garyo>	I'd be happy if we can make that true.
 450 18:08:42 <cdavid>	currently, my understanding is that MSVS_VERSION control devenv path
 451 18:08:52 <garyo>	... which is what?
 452 18:08:55 <garyo>	IDE?
 453 18:08:59 <cdavid>	yes
 454 18:09:07 <cdavid>	you can build at the command line as well:
 455 18:09:13 <cdavid>	devenv foo.sln /build "Release"
 456 18:09:22 <cdavid>	which is my only use of the IDE, personally :)
 457 18:09:24 <Jason_at_intel>	that is a custom command
 458 18:09:35 <garyo>	got it.  But still related to "solution generation", not compiler.
 459 18:09:36 <cdavid>	but this command is found by the msv*c* batch file
 460 18:09:58 <garyo>	ack
 461 18:10:08 <Jason_at_intel>	??
 462 18:10:12 <cdavid>	the problem is that currently, if MSVS* and MVSC* refer to different version, the environment is screwed up
 463 18:10:13 <Jason_at_intel>	found?
 464 18:10:36 <cdavid>	sorry, I meant if the msvc batch file is executed, devenv will be in the path
 465 18:10:42 <garyo>	cdavid: aha, that explains a lot.
 466 18:10:54 <Jason_at_intel>	yes that is true
 467 18:11:11 <Jason_at_intel>	even if you did what i have.. this would be true
 468 18:11:21 <garyo>	(like the SCONS_MSCOMMON_DEBUG trace I sent you earlier today)
 469 18:11:25 <cdavid>	the msvs project stuff requires any IDE stuff ?
 470 18:11:34 <cdavid>	or is it pure python code ?
 471 18:11:40 <garyo>	So what I'm hearing is MSVS_VERSION and MSVC_VERSION cannot realistically be different.
 472 18:11:59 <garyo>	at least how things are today.
 473 18:12:05 <cdavid>	it could if MSVS_VERSION would only control project generation, assuming project generation does not depend on any external tool
 474 18:12:05 <Jason_at_intel>	I think msvs is just python code
 475 18:12:49 <garyo>	So let's move in that general direction.
 476 18:13:00 <Jason_at_intel>	Steve.. do you have a better project generator for vs?
 477 18:13:00 <cdavid>	What about having a  new variable to control the project generation, and deprecate MSVS_VERSION ?
 478 18:13:00 <bdbaddog>	but can we make the MSVS_VERSION change in 1.3?
 479 18:13:11 <garyo>	How about if we make sure that the msvs bat file doesn't get loaded by default?
 480 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
 481 18:13:57 <garyo>	bdbaddog: maybe too short a time scale to do it all.
 482 18:14:00 <Jason_at_intel>	cdavid : agree
 483 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)
 484 18:14:29 <garyo>	How about for 1.3 we just say MSVC_VERSION and MSVS_VERSION should be the same.
 485 18:14:38 <garyo>	(or MSVS_VERSION unset)
 486 18:14:57 <garyo>	cdavid: +1
 487 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
 488 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?
 489 18:15:02 <Jason_at_intel>	I think we want to migrate allow both.. but preffer MSVC_
 490 18:15:29 <Jason_at_intel>	if both are set
 491 18:15:38 <garyo>	I like David's way. @bdbaddog: we just need error checking, which I have some of.
 492 18:16:10 <cdavid>	I think the main issue is testing
 493 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.
 494 18:16:19 <cdavid>	yes
 495 18:16:31 <cdavid>	my changes are in the msvc_changes branch, BTW - master tracks the trunk
 496 18:16:45 <garyo>	cdavid: thanks, I'll check that.
 497 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?
 498 18:17:14 <cdavid>	I think Jason started something in that direction, right ?
 499 18:17:25 <garyo>	Jason, don't you have some VMs?
 500 18:17:26 <cdavid>	which page, I don't remember
 501 18:17:41 <Jason_at_intel>	I need to put it online.. and it was for Parts work with the new tool chain stuff
 502 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
 503 18:18:09 <bdbaddog>	so we have no 2003, 2005, or vs6 ?
 504 18:18:17 <Jason_at_intel>	so it does not test the Scons version of the tools
 505 18:18:18 <cdavid>	I have VS 2003 somewhere
 506 18:18:24 <garyo>	I have VS 2003 & 2005 on the same machine, and some other stuff.  Maybe an old vs6 machine or vm.
 507 18:18:31 <cdavid>	vs 6 is harder
 508 18:18:35 <Jason_at_intel>	I have vc6 -2008
 509 18:18:52 <bdbaddog>	can any of these be setup as buildbot slaves? ;)
 510 18:19:03 <cdavid>	not in my case, as it is on my laptop
 511 18:19:03 <garyo>	The tests have to be run manually though, for now.
 512 18:19:25 <garyo>	Mine are "corporate" and I don't think I can put buildbot on them.
 513 18:19:26 <cdavid>	you can automatically get the tarballs from github, at least
 514 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
 515 18:19:36 <stevenknight>	(bdbaddog:  speaking of buildbot, master's down.  i logged in to the system, any reason not to restart master?)
 516 18:19:48 <Jason_at_intel>	mean time i can test manually and report out
 517 18:20:04 <bdbaddog>	(steve: no reason not to restart, need to figure out why it's not restarting at reboot)
 518 18:20:07 <garyo>	Jason, you saw David's testcase hello.c/SConstruct, right?
 519 18:20:23 <Jason_at_intel>	nope
 520 18:20:31 <garyo>	I'll forward it to you.
 521 18:20:34 <Jason_at_intel>	ok
 522 18:21:07 <Jason_at_intel>	run it and give you the outputs?
 523 18:21:10 <garyo>	OK, so once that's all squared away, we put out another ckpoint?
 524 18:21:16 <bdbaddog>	yes.
 525 18:21:16 <garyo>	Jason: it'll be obvious.
 526 18:21:19 <cdavid>	yes
 527 18:21:22 <Jason_at_intel>	ok
 528 18:21:26 <bdbaddog>	then 2 weeks then 1.3
 529 18:21:28 <Jason_at_intel>	will wait to get it and see then
 530 18:21:35 <cdavid>	I will clean up a few things in the branch, normalize MSVC/MSVS
 531 18:21:39 <cdavid>	for the warnings ?
 532 18:21:50 <cdavid>	I try to use scons warnings but could not get them to pring
 533 18:21:56 <cdavid>	using SCons.warning
 534 18:21:58 <garyo>	I'll send you what I have which deals with missing cross-architectures
 535 18:22:20 <garyo>	but I use SCons.Error for a manually-specified missing TARGET_ARCH.
 536 18:22:45 <garyo>	Warnings don't print unless they're enabled by default somewhere.
 537 18:22:50 <garyo>	SCons.Warnings or something?
 538 18:22:51 <Jason_at_intel>	you mean bad TARGET_ARCH?
 539 18:23:17 <garyo>	Jason: uninstalled TARGET_ARCH, like I don't have the x86-64 compiler installed on my VS2003 machine.
 540 18:23:39 <Jason_at_intel>	ahh tool setup combo that can 't be done
 541 18:23:46 <garyo>	one other thing, there's a nice arch.py in mscommon, but I don't think it's used.
 542 18:23:57 <Jason_at_intel>	I do the same I think i have a toolset error based on Scons UserError
 543 18:24:01 <garyo>	(hm, maybe I was looking on trunk though.)
 544 18:24:13 <garyo>	Jason: right.
 545 18:24:22 <cdavid>	I have changed arch.py
 546 18:24:29 <cdavid>	using dict instead of objects
 547 18:24:37 <Jason_at_intel>	I thought arch was moved to Platform?
 548 18:25:00 <cdavid>	the best would be to push this in a more general manner for cross compilation on any platform
 549 18:25:02 <garyo>	ok.
 550 18:25:13 <stevenknight>	cdavid:  Script/Main.py has the list of warnings enabled by default
 551 18:25:16 <cdavid>	but currently, I don't see this happening with the current tool infrastructure
 552 18:25:17 <bdbaddog>	agreed, but let's minimize the changes for 1.3
 553 18:25:41 <cdavid>	so we can keep the arch values in the MS tools subdirectory for now ?
 554 18:25:53 <garyo>	@cdavid: right, impossible in limited time.
 555 18:26:05 <Jason_at_intel>	cdavid: have you seen what i did in Parts for this? based on current tool stuff?
 556 18:26:27 <Jason_at_intel>	it may not be that hard in reality
 557 18:26:27 <cdavid>	jason: I have started looking at the doc, but did not have the time to really go deep down
 558 18:26:47 <Jason_at_intel>	if you get time and have question/thought let me know
 559 18:26:55 <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.)
 560 18:26:58 <cdavid>	steven: thanks, I will look there
 561 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
 562 18:27:33 <Jason_at_intel>	ok so for 1.3
 563 18:28:17 <bdbaddog>	guestimate on timeline?
 564 18:28:35 <cdavid>	I will do all the fixes discussed now within today
 565 18:28:37 <garyo>	it'll take a couple of days to test, I'll get my stuff to David tomorrow
 566 18:28:43 <cdavid>	so tomorrow for people in the US
 567 18:28:43 <Jason_at_intel>	1) SDK - fixed
 568 18:28:45 <Jason_at_intel>	2) testing needed .. but we think it is about there
 569 18:28:46 <Jason_at_intel>	3)MSVC_ MSVS_ do what David suggests
 570 18:28:48 <Jason_at_intel>	4) TARGET_ARCH??
 571 18:28:56 <cdavid>	it is done
 572 18:28:58 <garyo>	TARGET_ARCH is working now.
 573 18:29:01 <cdavid>	I mean TARGET_ARCH is working
 574 18:29:25 <cdavid>	TARGET_HOST/TARGET_ARCH works for all combinations x86/amd64 with VS 2008
 575 18:29:32 <Jason_at_intel>	so then 2) is all that is needed? and a fix to make 3) happen
 576 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?
 577 18:29:42 <Jason_at_intel>	what about ia64
 578 18:29:44 <cdavid>	I have no support for itanium, though
 579 18:30:04 <garyo>	@bdbaddog: no, I think we're close, just wait til Thursday or Friday if that's OK w/ you.
 580 18:30:07 <Jason_at_intel>	ok not a big deal .. I have it for my stuff
 581 18:30:09 <cdavid>	bdbaddog: would next monday be good for a ck ?
 582 18:30:15 <bdbaddog>	sure.
 583 18:30:17 <garyo>	+1
 584 18:30:28 <cdavid>	The pb with itanium is that I cannot test it in any way
 585 18:30:38 <cdavid>	vmware does not support itanium :)
 586 18:30:46 <Jason_at_intel>	you can only test cross build for ia64
 587 18:31:02 <garyo>	... but you can't run the result.
 588 18:31:04 <cdavid>	I can test it runs, not that it produces the right binary
 589 18:31:18 <Jason_at_intel>	with out a ia64 window system native case is hard to test .. I know ..
 590 18:31:36 <cdavid>	I wonder if wine supports ia - I guess not
 591 18:31:37 <Jason_at_intel>	agree... can test the runs
 592 18:31:44 <Jason_at_intel>	can't test :-)
 593 18:31:53 <cdavid>	wine can runs 64 bits command line binaries, now
 594 18:31:58 <bdbaddog>	I think it's a very small percentage of users using IA64.
 595 18:32:07 <Jason_at_intel>	well I would not want to emulate ia64
 596 18:32:09 <garyo>	OK, sounds like a plan.  fix/test ASAP, checkpoint, then 2 wks to 1.3.
 597 18:32:11 <bdbaddog>	lets assume compiling is fine, and wait for bugs to prove otherwise..
 598 18:32:13 <Jason_at_intel>	ya very small
 599 18:32:17 <Jason_at_intel>	mostly cluster people
 600 18:32:24 <bdbaddog>	k.
 601 18:32:34 <bdbaddog>	I"m going to turn into a pumpkin in 5.
 602 18:32:47 <garyo>	send pix.
 603 18:32:53 <stevenknight>	this all sounds quite good
 604 18:32:57 <bdbaddog>	o.k. so I guess updates as to what progress on dev mailing list?
 605 18:33:03 <cdavid>	so gary, can you send me the patches ?
 606 18:33:22 <garyo>	yes, we'll all keep in touch.  cdavid: tomorrow AM I hope.  I have the right branch now :-)
 607 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
 608 18:34:06 <cdavid>	Jason: the changes are in a git branch, not in svn for now
 609 18:34:23 <Jason_at_intel>	hmm does git work on windows?
 610 18:34:24 <garyo>	Jason: it's not on trunk, only David's git repo, and msvc_fixes branch in there.
 611 18:34:39 <garyo>	git works fine on Windows.  Use msys git.
 612 18:34:45 <bdbaddog>	or cygwin git.
 613 18:34:46 <Jason_at_intel>	does git support a proxy servers?
 614 18:34:47 <bdbaddog>	;)
 615 18:34:51 <garyo>	msys is better these days.
 616 18:34:54 <bdbaddog>	ahh.
 617 18:34:57 <cdavid>	yes, but throught http
 618 18:35:03 <cdavid>	better
 619 18:35:05 <garyo>	git can work via http or ssh.
 620 18:35:07 <bdbaddog>	o.k. I"m gone. Thanks to all!
 621 18:35:08 <garyo>	(or native)
 622 18:35:13 <garyo>	bye Bill!
 623 18:35:17 <cdavid>	I am removing some old stuff in github, and you can just grab a tarball
 624 18:35:17 <bdbaddog>	l8r
 625 18:35:21 <Jason_at_intel>	ok .. gary can you give me the link
 626 18:35:23 <cdavid>	bye Bill
 627 18:35:28 *	bdbaddog has quit ("ChatZilla 0.9.85 [Firefox 3.5.4/20091016081620]")
 628 18:35:29 <Jason_at_intel>	in teh e-mail you will give me
 629 18:35:33 <garyo>	Will do, Jason.
 630 18:35:36 <Jason_at_intel>	thanks
 631 18:36:03 <garyo>	OK, thanks all!  Good night.
 632 18:36:11 <Jason_at_intel>	night!
 633 18:36:17 <stevenknight>	great work guys, good night
 634 18:36:26 <cdavid>	http://github.com/cournape/scons/archives/msvc_fixes
 635 18:36:34 <Jason_at_intel>	oh one question
 636 18:36:38 <garyo>	?
 637 18:36:43 <Jason_at_intel>	subst()
 638 18:36:53 <Jason_at_intel>	any idea when this will be addressed?
 639 18:37:03 <Jason_at_intel>	I am 90% sure this is why SCons is slow
 640 18:37:06 <stevenknight>	what part of it?  how generally grungy it is?
 641 18:37:07 <garyo>	speed? functionality? quoting?
 642 18:37:19 <Jason_at_intel>	speed
 643 18:37:29 <stevenknight>	Jason_at_intel:  re: 90%:  kind of
 644 18:37:42 <cdavid>	Nodes are a big reason as well
 645 18:37:48 <stevenknight>	it's slow, but there are also algorithmic inefficiencies
 646 18:37:57 <cdavid>	depends on the projects, though
 647 18:37:59 <stevenknight>	we do a lot of string re-expansion multiple times
 648 18:38:00 <Jason_at_intel>	well there might be a node issues as well with speed
 649 18:38:16 <Jason_at_intel>	so the simple test is this
 650 18:38:32 <cdavid>	nodes cause memory pb and too many function calls, which are very slow in python
 651 18:38:46 <Jason_at_intel>	take 6000 node ( like read all the headers in Boost) and install them to a directory
 652 18:38:52 <Jason_at_intel>	take about 8 seconds
 653 18:39:09 <Jason_at_intel>	to process the env.Install()
 654 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
 655 18:39:21 <stevenknight>	seems faster, but not benchmarked
 656 18:39:29 <Jason_at_intel>	remove the subst() call in Arg2Node.... 1 second
 657 18:39:51 <garyo>	!
 658 18:39:59 <stevenknight>	yow
 659 18:40:28 <cdavid>	and you lose nothing by not calling subsg in Arg2Node ?
 660 18:41:13 <Jason_at_intel>	the builder has to turn the strings into nodes
 661 18:41:31 <Jason_at_intel>	the node creation in Arg2Node  does a subst of teh string value first
 662 18:41:46 <garyo>	In real life you do have to do a subst there, but if it could be super fast...
 663 18:41:48 <Jason_at_intel>	even if the string is fine.. nothing to do, this takes time
 664 18:42:14 <stevenknight>	or if we can avoid work if it doesn't need subst()
 665 18:42:25 <stevenknight>	subst() itself checks for '$' in the string and just returns
 666 18:42:26 <stevenknight>	but
 667 18:42:47 <stevenknight>	Jason_at_intel's pointing out there's a bunch of work in Env.py before we even call subst()
 668 18:43:03 <stevenknight>	i wonder how much time gets saved if we move the '$' check
 669 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
 670 18:43:42 <Jason_at_intel>	in fact to help with speed issues.. if we can get this Scons to work in iron python
 671 18:43:59 <Jason_at_intel>	I can give you very detailed data on what is the performance issues
 672 18:44:18 <stevenknight>	? env isn't critical path?  that's where arg2nodes() lives
 673 18:44:20 <garyo>	but wait, stay on topic.  You remove the subst, it drops the time from 8 to 1 sec.
 674 18:44:21 <Jason_at_intel>	as I can use our tools on .net code..
 675 18:44:43 <garyo>	So where's the time going if subst() shortcuts when there's no $?
 676 18:44:44 <Jason_at_intel>	ya... arg2node is a big fish.. not it slow because of subst
 677 18:45:07 <stevenknight>	?  okay, you're really confusing me
 678 18:45:08 <garyo>	OK, good -- figure out which part of arg2node is causing the slowdown.
 679 18:45:21 <stevenknight>	you say if you remove the subst() call from arg2nodes() you get an 87.5% speedup
 680 18:45:31 <Jason_at_intel>	So when i tested this for a few days it was teh subst
 681 18:45:34 <stevenknight>	then you tell me that arg2nodes() is not slow because of subst()
 682 18:45:46 <stevenknight>	which is it?
 683 18:46:09 <Jason_at_intel>	I made sure the string i had where fully subst'ed before arg2node
 684 18:46:20 <cdavid>	By everone - I will work on updating scons in the meantime
 685 18:46:26 <Jason_at_intel>	the simple find was that something in the subst call itself is slow
 686 18:46:29 <stevenknight>	so your speedup wasn't removing subst() from arg2nodes()
 687 18:46:35 <stevenknight>	?
 688 18:46:48 <Jason_at_intel>	so yes.. i did three basic tests
 689 18:46:55 <Jason_at_intel>	1) my base line
 690 18:47:05 <Jason_at_intel>	2) with string fully substed
 691 18:47:20 <Jason_at_intel>	3) with subst in arg2node commented out
 692 18:47:42 <Jason_at_intel>	1) 2) 8,6 seconds
 693 18:47:51 <Jason_at_intel>	3) 1 ish
 694 18:48:59 <garyo>	Well that's pretty clear.
 695 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
 696 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?
 697 18:49:41 <stevenknight>	no, there are two layers to subst
 698 18:49:50 <stevenknight>	there's the env.subst() wrapper that does a bunch of set up
 699 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
 700 18:50:08 <stevenknight>	and there's the Subst.scons_subst() function that does the heavy lifting
 701 18:50:33 <stevenknight>	the Subst.scons_subst() function will look for a '$' and return if everything's expanded
 702 18:50:46 <stevenknight>	but that's *after* the env.subst() wrapper has done a bunch of set up
 703 18:50:53 <stevenknight>	originally, that was a thin layer
 704 18:50:57 <stevenknight>	but it's grown over time
 705 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
 706 18:51:51 <Jason_at_intel>	I can give it a try
 707 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
 708 18:52:24 <stevenknight>	yeah
 709 18:52:40 <Jason_at_intel>	I would rather not have to add more code to do it before
 710 18:52:49 <stevenknight>	i think the prototype i half-finished is promising
 711 18:53:00 <stevenknight>	but when i stepped back and tried to redo things fresh
 712 18:53:13 <stevenknight>	the big hassle is actually subst_list()
 713 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
 714 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
 715 18:54:10 <stevenknight>	cool
 716 18:54:28 <Jason_at_intel>	ya honestly in parts i have my own code for this
 717 18:54:46 <Jason_at_intel>	the subst and return a list logic was odd for me
 718 18:54:52 <Jason_at_intel>	code not figure it out
 719 18:54:57 <stevenknight>	"odd" is putting it kindly
 720 18:55:22 <Jason_at_intel>	well I am trying to be postive
 721 18:55:25 <Jason_at_intel>	:-)
 722 18:55:37 <stevenknight>	much appreciated... :-)
 723 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
 724 18:56:58 <Jason_at_intel>	nee->need
 725 18:57:42 <Jason_at_intel>	I think the node code coudl be a little better in the creation for the global file list
 726 18:58:00 <Jason_at_intel>	but that does not seem to be a big fish in speed so far
 727 18:58:26 <Jason_at_intel>	we have about 100,000 source files being process and copied in our builds
 728 18:58:45 <stevenknight>	we need a performance-testing infrastructure in the buildbots
 729 18:59:16 <stevenknight>	something that makes it easy to add tests like your 6000 node config
 730 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
 731 18:59:21 <stevenknight>	time and graph the results
 732 18:59:51 <Jason_at_intel>	I will try to send you a test sample based on boost
 733 19:00:19 <stevenknight>	okay, i need to finish
 734 19:00:23 <Jason_at_intel>	ok
 735 19:00:34 <stevenknight>	i'll send you guys some off-line thoughts about some things
 736 19:00:36 <stevenknight>	'night
 737 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
 738 19:01:00 <Jason_at_intel>	later!
 739 19:03:16 *	Jason_at_intel has quit ("ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458]")
 740 20:00:33 *	garyo has quit ("Leaving.")
 741 23:49:41 *	cdavid has quit ("Page closed")
 742 

BugParty/IrcLog2009-11-03 (last edited 2009-11-11 01:05:29 by ip68-7-77-81)