Wiki

Clone wiki

SCons / BugParty / IrcLog2010-07-06

16:49:42 * Garyo (~chatzilla@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has joined #SCONS 16:49:43 * jason_at_intel_ (~chatzilla@210.sub-69-97-59.myvzw.com) has joined #SCONS 16:55:13 * sgk_ (~sgk@c-24-4-65-89.hsd1.ca.comcast.net) has joined #SCONS 16:56:18 * sgk_ is now known as sgk 17:05:20 * GregNoel has arrived... 17:06:51 <GregNoel> Lots to do today; shall we start? 17:06:59 <Garyo> I'm ready 17:07:02 <sgk> let's go 17:07:05 <jason_at_intel_> ready 17:07:04 <GregNoel> 2443 closed by Steven 17:07:04 <GregNoel> 2570 consensus 2.1 p1 Gary 17:07:04 <GregNoel> 2551 consensus 2.1 p4 Steven 17:07:04 <GregNoel> That clears off the 1.3 issues 17:07:04 <GregNoel> 2549 does Russel have commit? 17:07:46 <Garyo> 2549: not that I've seen 17:07:57 <sgk> i don't believe he does 17:08:11 <GregNoel> so someone will have to proxy it for him 17:08:44 <sgk> i can do the integration 17:09:03 <Garyo> thanks, sounds good 17:09:36 <GregNoel> done 17:09:40 <GregNoel> 2560 consensus anytime p1 Greg 17:09:40 <GregNoel> 2564 consensus Gary+Greg this summer 17:09:40 <GregNoel> 2636 If Russel doesn't want it, I can go with future p3. 17:09:40 <sgk> do we want a new issue to track the idea of a WhereIs() for LIBPATH ? 17:09:51 <GregNoel> Yes, I'll create it. 17:09:55 <sgk> thnx 17:10:03 <Garyo> 2564: will have to be August for me, ok Greg? 17:10:40 <GregNoel> Garyo, late August is fine; first week is family holiday 17:10:57 <Garyo> ok. Shouldn't be all that painful I think. 17:11:25 <GregNoel> 2637 fixed by Greg 17:11:25 <GregNoel> 2638 consensus anytime p2 Greg 17:11:25 <GregNoel> 2648 I suppose research is OK, but there are starting to be too many research issues that aren't getting processed (and that includes me). 17:12:02 <Garyo> me too 17:12:06 <sgk> me three 17:12:34 <sgk> hmm... 17:12:52 <sgk> would it help or hurt if we also put the research issues on the list to review every bug party ? 17:12:54 <sgk> status update, etc. 17:12:59 <jason_at_intel_> Don't know enough ... 17:13:05 <sgk> might provide additional incentive to look at them instead of letting them languish 17:13:06 <Garyo> Eek, then we'd have to do them! :-) 17:13:10 <sgk> if only to get them off the list 17:13:16 <sgk> :-) 17:13:30 <GregNoel> sgk, not a bad idea; we certainly need some concept of a time limit. 17:13:51 <Garyo> Greg: time limit ++ 17:13:58 <sgk> agreed 17:14:25 <jason_at_intel_> +1 17:14:25 <Garyo> So... sgk, still want to take this one as research? 17:14:37 <sgk> 2648? yes 17:14:39 <GregNoel> Maybe p1 issues are reviewed, and each party increases the priority of non-p1 issues? 17:15:00 <Garyo> Greg: I was almost going to propose that but didn't want to make more work. 17:15:06 <Garyo> But I like it. 17:15:25 <GregNoel> Yeah, it'd be a hassle, but it might be worth it 17:16:05 <Garyo> If you don't mind I think it's a great way to go. RT (our bug tracker at work) does that automatically each night. 17:15:19 <sgk> of research issues, yes? 17:15:23 <sgk> not all issues 17:15:41 <GregNoel> sgk, yes, only research issues. 17:15:59 <sgk> if it can be done without too much extra hassle, it sounds worthwhile 17:16:02 <GregNoel> So, 2648, what priority? 17:16:28 <Garyo> p3 or p4, since it's user error anyway 17:16:47 <GregNoel> either works for me 17:16:45 <sgk> since i'm on hook, p4 17:16:53 <GregNoel> p4, done 17:16:55 <sgk> that'll give me three bug partys before we review it again... :-) 17:17:21 <GregNoel> 2649 Steven just updated it and I haven't had time to look at it. Are there other opinions? 17:17:29 <Garyo> Let's make an effort to get the existing research issues cleared up before we go and prioritize all of them 17:17:49 <sgk> Garyo++ 17:19:01 <GregNoel> Was that about 2649 or still on the research issues? 17:19:07 <Garyo> 2649: sounds like greg & sk are figuring out if it's an issue or not, right? 17:19:20 <jason_at_intel_> it seems like this need to be looked into more 17:19:26 <GregNoel> yes, but what to do with it? 17:19:35 <sgk> Jason_at_intel: well, that's kind of what we're doing with it... :-) 17:19:43 <GregNoel> review next time? 17:19:45 <jason_at_intel_> All i know is that Aliases and Depends don't work together and i would like them to myself 17:20:03 <jason_at_intel_> :-) 17:20:19 <Garyo> Jason: but look at this issue. Steven thinks there's nothing wrong with Alias once 2443 is fixed. 17:20:39 <sgk> well, more "hoping" than "thinking," but yes in principal... :-) 17:21:03 <sgk> Jason_at_intel: we need an actual test case 17:21:11 <sgk> i'm too close to the code to create one 17:21:12 <jason_at_intel_> right.. so do we want to link these items? 17:21:22 <Garyo> Your dep graph is pretty clear there. (Maybe we should tag Alias nodes visibly in dep graphs??) 17:21:49 <sgk> Garyo: yeah, we should probably have a Python-like <Alias 'sub1/a.lib'> or some such 17:21:58 <sgk> or at least a mode that displays stuff like that 17:22:20 <sgk> well, the items aren't linked per se 17:22:26 <Garyo> I'd like that, for clarity. I'd be happy with (Alias) after the name. 17:22:46 <sgk> the fix for the previous issue of using Depends() without Builders is already committed 17:22:41 <GregNoel> The curve here is that Alias() can supposedly have an action. 17:23:09 <Garyo> Greg: you're right, I'm just sidetracking. 17:23:12 <sgk> this is about trying to make sure, while our attention is here, that we get similar problems in other areas (if they exist) 17:23:26 <GregNoel> point. 17:24:26 <sgk> The fix I submitted for no-Builder Depends() isn't specific to any node type 17:24:28 <GregNoel> My attempts to use Alias() with an action have been hit-and-miss; sometimes they work, sometimes they don't, and I don't see a pattern. 17:24:47 <sgk> so there's a decent chance that it makes the Alias() case better, at least 17:25:03 <jason_at_intel_> it seems that a test case should not be to hard for this one 17:25:30 <sgk> cool, if you can come up with one, that would be great 17:25:49 <Garyo> OK, how about we close this one next time if no test case shows up? 17:26:01 <GregNoel> I think time is up on this issue; review next time? 17:26:17 <GregNoel> Or close it... {;-} 17:26:01 <sgk> that sounds good 17:26:21 <jason_at_intel_> is it correct to say this bug is related to stuff like : 17:26:22 <jason_at_intel_> x=env.Alias("foo",action) 17:26:23 <jason_at_intel_> env.Depends(env.Alias(boo,x)) 17:26:51 <Garyo> huh? 17:27:06 <jason_at_intel_> last line should be env.Depends(env.Alias(boo),x) 17:27:20 <Garyo> What's boo? 17:27:31 <jason_at_intel_> you can't maps depends to to alias 17:27:32 <jason_at_intel_> "boo" 17:27:39 <jason_at_intel_> just an alias name 17:27:59 <jason_at_intel_> foo has an actions.. so i can say Scons foo 17:28:04 <Garyo> so the Alias "boo" depends on the Alias "foo" which has an action? 17:28:08 <jason_at_intel_> but i can say't scons boo 17:28:16 <sgk> jason_at_intel: if that's a use case that fails, sure 17:28:37 <jason_at_intel_> but why? 17:28:40 <Garyo> jason: if it really fails, put it in this bug. (imho) 17:28:50 <jason_at_intel_> Sure. 17:28:52 <sgk> the problem is that on our own we're not successfully characterizing what exactly "this bug" is... :-) 17:29:07 <Garyo> #2649 17:29:12 <GregNoel> 2650 I'm also interested in this issue, so it could go on my plate instead. 17:29:53 <Garyo> 2650: if this works it could be a huge enhancement! 17:30:04 <sgk> GregNoel: if you want 2650, that'd be great 17:30:05 <jason_at_intel_> +1 for 2650 17:30:41 * sgk changes the relevant cell in the spreadsheet... 17:30:20 <Garyo> I don't care if you make a SEP for it really. 17:30:47 <GregNoel> Well, I'm beginning to agree with you after the discussion with Russel. 17:31:22 <Garyo> I found the SEP thing really useful when doing the site_scons dirs. 17:31:17 <jason_at_intel_> :-) 17:31:23 <jason_at_intel_> like the additions 17:31:51 <GregNoel> OK, draft a SEP, review next time? 17:31:57 <Garyo> great 17:32:00 <sgk> sounds good 17:32:12 <GregNoel> done 17:32:15 <GregNoel> 2651 17:33:08 <Garyo> I could probably look at this for 2.2 17:33:13 <Garyo> or 2.3 17:33:27 <Garyo> but not 2.1 17:33:55 <Garyo> I have plenty of rpm-based machines around 17:34:05 <Garyo> 2.3 p4 garyo 17:34:11 <sgk> works for me 17:34:13 <GregNoel> works for me 17:34:31 <GregNoel> (jinx) 17:34:20 <GregNoel> 2652 Gary can have it, but what priority? 17:34:55 <jason_at_intel_> does this have to be loaded in the default builder to work? 17:35:03 <sgk> p3 17:35:05 <Garyo> I have a bunch of other things, p3 is good for me 17:35:14 <Garyo> Jason: ? 17:35:28 <GregNoel> p3 works for me; done 17:35:45 <GregNoel> 2653 17:35:50 <sgk> jason_at_intel: "does this have to be loaded..." "this" == ? 17:35:56 <Garyo> 2653: how do you make a symlink on windows like that? 17:36:04 <sgk> he doesn't make it on Windows 17:36:09 <sgk> it's an NFS-mounted file system 17:36:18 <sgk> so it was made on Linux/BSD/what have you 17:36:21 <jason_at_intel_> I thought copyAs was a tool that has to be loaded to so it can be called 17:36:24 <Garyo> omg 17:36:31 <jason_at_intel_> that is why i am making a CCopy builder in Parts 17:36:36 <sgk> but it makes SCons gag, and we should at least be more graceful than a stack trace 17:37:03 <jason_at_intel_> so the gag might be python itself 17:37:19 <jason_at_intel_> windows has some rules about how files should be open 17:37:28 <sgk> give 2653 to me, my systems at work are set up so I can test this 17:37:32 <GregNoel> I'm lost; what are we talking about? 17:37:40 <jason_at_intel_> and the standard way python does it violate the rules 17:37:50 <Garyo> I'm talking about 2563 17:37:50 <sgk> 2653 17:37:55 <jason_at_intel_> 2653? 17:38:11 <Garyo> sorry 2653 17:38:37 <jason_at_intel_> Anyways.. I been working on work around to the issue in Parts 17:38:42 <GregNoel> OK, then why does CopyAs() have to be loaded in 2653? 17:39:11 <jason_at_intel_> that was a different issue :-) 17:39:28 <jason_at_intel_> I thought copyAs was a tool that was not loaded by default 17:39:32 <jason_at_intel_> so the user could not call it 17:39:49 <jason_at_intel_> but i could be wrong 17:39:46 <GregNoel> What does that have to do with documenting it? 17:40:10 <Garyo> Re: 2653, Justin has just replied w/ how he makes these symlinks (mklink /d). 17:40:16 <sgk> GregNoel: nothing directly, talk of documenting CopyTo()/CopyAs() prompted jason_at_intel to wonder about needing to load it 17:40:31 <jason_at_intel_> that it would need to be documented to for a manual load.. or we would want to have it load by default 17:40:47 <sgk> Garyo: understood that more modern Windows file systems can make symlink-like things 17:41:03 <sgk> I'll try to look at that behavior, too 17:41:21 <jason_at_intel_> so on windows.. with 2653... you all know who to make symlinks and hardlinks 17:42:22 <Garyo> Jason: I see your point re: CopyTo/CopyAs. I'll note that in the doc. However: shouldn't they just be loaded standard like Copy? 17:42:39 <Garyo> Why aren't they? 17:42:41 <sgk> it looks to me like CopyTo() / CopyAs() are loaded by default 17:42:47 <sgk> they're in Tool/filesystem.py 17:43:05 <sgk> and that's in the default load list 17:43:12 <sgk> at least in current trunk 17:43:24 <jason_at_intel_> I might be out of date on this... 17:43:31 <GregNoel> Garyo, yes, I seem to recall an issue to combine Install{,As}, Copy, and Textfile into one Tool. 17:43:50 <jason_at_intel_> last time i tried it.. it was not there by default 17:44:35 <Garyo> Ah yes, I see in Tool/<ins>init</ins>.py there's even a relevant comment. But it does look like it should be on by default. I'll check. 17:44:42 <GregNoel> We're getting off-point... 17:44:58 <sgk> yes 17:45:00 <sgk> back to 2653 17:45:10 <sgk> 2.1 p2 sgk 17:45:16 <sgk> any objections ? 17:45:25 <GregNoel> works for me; done 17:45:27 <jason_at_intel_> nope 17:45:29 <Garyo> good 17:45:31 <GregNoel> 2654 fixed by Steven 17:45:31 <GregNoel> 2655 17:46:05 <sgk> honestly not sure what to do here 17:46:22 <sgk> i'd like to get rid of os.chdir(), but the backwards-compatibility issues are scary 17:46:25 <jason_at_intel_> so as i see it .. no os.chdir is best .. but that means removing an API 17:46:28 <GregNoel> Steven's point is good; it means that things like Node.read() need to be implemented before we can do this. 17:47:01 <Garyo> That'd be a big project and change for users. Is this patch useful in the meantime? 17:47:04 <sgk> and we have to go through a deprecation cycle to remove the ability to just do an open('file', 'r') and have it interpreted relative to the SConscript directory 17:47:05 <jason_at_intel_> node.read()?? 17:47:35 <sgk> jason_at_intel: File nodes should, from the start, have implemented methods like Python file handles 17:47:42 <sgk> .read(), .readlines(), etc. 17:48:09 <jason_at_intel_> ok, so this means that we should preffer to use only SCons file API, not systems one 17:48:42 <Garyo> That would be necessary if we wanted to get rid of os.chdir() completely. But I think that's fraught with peril. 17:48:53 <Garyo> as well as being more work than we think. 17:49:41 <jason_at_intel_> I guess i will see how bad this can be in Parts... 17:50:01 <jason_at_intel_> I will set it up to not have Scons chdir 17:49:52 <Garyo> Frankly I think this patch is very sensible as it stands. 17:50:22 <jason_at_intel_> :-) 17:50:03 <sgk> back to Garyo's question: i think the patch is useful in the meantime 17:50:15 <sgk> so let's apply it for 2.1 17:50:26 <sgk> and we should have a new issue to get rid of os.chdir() ? 17:50:19 <GregNoel> If we're going to change the API in the direction of no os.chdir(), I'd worry about applying this as a band-aid in the short term. 17:50:35 <Garyo> Greg: why? 17:51:17 <GregNoel> Two changes to the same API. And it does make a non-backward-compatible change, so it'll require deprecation... 17:51:57 <sgk> two changes? 17:51:56 <jason_at_intel_> I think this need many steps 17:52:02 <Garyo> Maybe I didn't look carefully. I thought it doesn't change the API, just what dir you're in when duplicate=False. 17:52:04 <sgk> oh 17:52:05 <GregNoel> sgk, why a new issue? Isn't 824 sufficient? 17:52:28 <sgk> oh, i forgot about 824 17:52:40 <sgk> that's sufficient, just so long as we track that issue 17:52:51 <jason_at_intel_> add file.open stuff, make the handling more consistent for os. stuff and migrate overtime 17:52:53 <sgk> (i mean the general issue of os.chdir()) 17:52:56 <Garyo> I think changing to the build dir when duplicate=False is just a bug, pure & simple. The first build gets one dir, the second gets a different one. 17:53:13 <sgk> yep, i've come around to that 17:54:00 <GregNoel> But with the patch, the -n case gets different things (assuming I understand it correctly) 17:54:22 <jason_at_intel_> I think the patch should be no worse than it is today 17:54:43 <jason_at_intel_> even today i can get directory creation with -n 17:55:08 <sgk> that doesn't mean we should add more instances of that; it's undesirable behavior 17:55:11 <jason_at_intel_> I did fix it with Steve suggestion to not make it worse 17:55:17 <sgk> iirc, the latest incarnation of the patch fixed that 17:55:22 <sgk> yeah 17:55:45 <GregNoel> No, I said -n gets different results; it's run in the source directory. 17:56:06 <jason_at_intel_> but there is some reason why it is made.. I did not remove that code.. it seemed tightly coupled with something i did not understand 17:56:28 <sgk> tight coupling r us... :-( 17:56:57 <jason_at_intel_> So Greg i don't understand your issue 17:57:17 <sgk> i think it's okay if -n behaves slightly differently 17:57:22 <jason_at_intel_> with -n and a 100% fresh build you always get the same results 17:57:54 <sgk> -n is usually a quick sanity check to see what might happen 17:58:26 <jason_at_intel_> only in the case when the directory should not have been made is it different with the patch.. I feel that it better form the user point of view 17:58:40 <sgk> that makes sense to me 17:58:41 <GregNoel> sgk, maybe, but I'd be surprised if it said it was going to do something and did something else... 17:58:58 <Garyo> Greg: I'm not following you 17:59:13 <Garyo> What are you telling it, and what is it doing? 17:59:24 <sgk> yeah, that's a fair point, but I don't think it outweighs having another honest-to-goodness use case that's outright broken 18:00:03 <GregNoel> I'll not push the point, but I suspect it'll end up as another FAQ. 18:00:34 <sgk> fair enough 18:00:28 <Garyo> ok, I think we beat this one into the ground :-) 18:00:39 <GregNoel> Yeah, decision? 18:00:50 <jason_at_intel_> so resolution? 18:01:03 <sgk> 2.1 p3 sk, i'll integrate 18:01:16 <sgk> i already have it teed up in a checked out tree 18:01:16 <GregNoel> done 18:01:19 <jason_at_intel_> add patch, or wait for a no os.chdir solution? 18:01:27 <Garyo> add patch 18:01:29 <jason_at_intel_> +1 18:02:24 <GregNoel> Ok, onward.... 2391? 18:02:25 <sgk> do we plow on a bit, or are we done for the night? 18:02:33 <jason_at_intel_> 2391? 18:02:35 <sgk> i probably have about 15 more minutes 18:02:49 <Garyo> let's keep on til sgk has to leave 18:02:59 <GregNoel> sgk, there are a couple that are consensus or close to it; we should at least hit those. 18:03:09 <sgk> onward 18:02:46 <sgk> 2391: 2.2 p2 sgk 18:03:26 <GregNoel> 2391, have at it. 18:03:47 <sgk> 2221: 2.1 p3 sgk (since I've been looking at subst()) 18:04:07 <sgk> if loonycyborg's patch doesn't work cleanly, i'll come back w/potential adjustment 18:03:59 <Garyo> agreed 18:04:01 <GregNoel> done 18:04:11 <GregNoel> 1891, skip 18:04:30 <jason_at_intel_> oh we see 2153 alot 18:05:28 <sgk> jason_at_intel: if you want to try to tackle 2153, sync up w/me off-line 18:05:37 <jason_at_intel_> Done :-) 18:05:48 <sgk> i think i can describe a general approach to a fix, if you want to do the heavy lifting 18:04:29 <GregNoel> 2145, same as 2221? 18:04:50 <sgk> 2145, yes: 2.1 p3 sgk 18:04:55 <Garyo> agreed 18:04:55 <GregNoel> done 18:05:07 <GregNoel> 2153, skip 18:05:19 <GregNoel> 2171 dup 18:05:45 <GregNoel> 2351, what milestone and priority? 18:06:02 <sgk> you mean 2357? 18:06:03 <GregNoel> er, 2357 18:06:33 <sgk> 2.1 p2 for that first step? 18:07:10 <GregNoel> Hmmm.... Yeah, I think so. 18:07:48 <GregNoel> I'd rather it were a bit later, though... 18:08:10 <Garyo> 2.2 is ok w/ me, 2.1 is chock full already 18:08:28 <sgk> yeah, 2.2 is fine 18:09:00 <sgk> 2.2 p2 18:08:32 <GregNoel> done 18:08:40 <GregNoel> 2375 18:09:02 <GregNoel> ...which will be the last one; none of the rest have significant comments. 18:09:05 <Garyo> anytime is ok 18:10:06 <Garyo> Greg: agreed, the rest are for next time. 18:10:14 <Garyo> Good progress! 18:10:14 <GregNoel> I'd rather make it a hard deadline; 'anytime' is almost as bad as 'research' 18:10:31 <sgk> i like garyo's 2.2 p2 suggestion 18:10:37 <sgk> too much already in 2.1 18:10:43 <GregNoel> done and done. 18:10:47 <sgk> but it's a good idea to clean up the command line this way thereafter 18:11:10 <GregNoel> concur 18:11:35 <sgk> all right, good stuff tonight 18:11:48 <Garyo> I feel like 2.1 is going to be really good. 18:12:05 <GregNoel> agreed 18:12:04 <sgk> cool 18:12:05 <jason_at_intel_> I am looking forward to it myself 18:12:17 <sgk> jason_at_intel: i'll try to look harder at your is_up_to_date() optimization 18:12:30 <sgk> at first glance it seems fine in principal 18:12:57 <jason_at_intel_> Sure... I need to review stuff gary talked about 18:13:07 <Garyo> sgk: if he's right that is a HUGE time savings. 18:13:16 <sgk> yeah 18:13:16 <Garyo> Definitely worth the investigation. 18:13:38 <jason_at_intel_> It might be easier for me to do some stuff in Parts as i have components which gives me some bounds 18:13:38 <sgk> i'll run it through the tests and see what pops out, my guess is there may be a few corner cases that depend on the behavior 18:13:51 <sgk> but if so, it'd be worth finding other ways to deal with them 18:14:12 <jason_at_intel_> but it would be great if we could pre-make node with out and env, or change it with out issues 18:14:21 <jason_at_intel_> or pickle the node 18:14:59 <Garyo> scary 18:15:05 <jason_at_intel_> anyways.. I will see what the tests show me tomorrow 18:15:35 <jason_at_intel_> I will sync with you on the visit steve this week 18:15:48 <jason_at_intel_> might want to know of a good hotel in the area 18:15:51 <sgk> jason_at_intel: okay, thanks 18:15:01 <sgk> any other last-minute pressing issues? 18:15:07 <Garyo> none 4 me 18:15:16 <GregNoel> nor me 18:15:24 <Garyo> I'll be gone til the 18th starting tomorrow 18:15:43 <sgk> vacation or work ? 18:15:49 <Garyo> vacation, Madrid 18:16:04 <sgk> great, have fun! 18:16:04 <jason_at_intel_> have fun Gary! 18:16:09 <Garyo> will do! 18:15:55 <GregNoel> Garyo, Next party is after that; we'll see you then. 18:16:04 <Garyo> Greg: sounds good. 18:16:14 <GregNoel> Garyo, Spain or Mississippi? 18:16:19 <sgk> 'night all 18:16:25 * sgk (~sgk@c-24-4-65-89.hsd1.ca.comcast.net) has left #SCONS 18:16:32 <Garyo> Spain -- actually I'm giving a talk, but it's mostly vacation anyway. 18:16:41 <GregNoel> Have fun... 18:16:45 <jason_at_intel_> night! and thanks! 18:16:54 <Garyo> 'night all. 18:17:00 <GregNoel> g'night 18:17:09 * Garyo (~chatzilla@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has left #SCONS 18:17:18 * jason_at_intel_ has quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.6/20100625231939])

Updated