Clone wiki

SCons / BugParty / IrcLog2008-04-12

The SCons wiki has moved to

09:01:26  *      stevenknight (n=[]( has joined #scons 
09:01:41  <stevenknight> good morning... 
09:01:43  <Greg_Noel>    stevenknight, hello 
09:01:55  <Greg_Noel>    Nobody else here, yet? 
09:01:59  <[CoryCohen](CoryCohen)>    Hi 
09:02:09  <stevenknight> [CoryCohen](CoryCohen):  hi 
09:02:09  <Greg_Noel>    Hello, you here for the bug party? 
09:02:18  <[CoryCohen](CoryCohen)>    Yeah, just to lurk really. 
09:02:25  <[CoryCohen](CoryCohen)>    Did you see me email to the dev list? 
09:02:48  <Greg_Noel>    probably; what was the subject? 
09:02:59  <stevenknight> yeah, the object file scanner for link dependencies? 
09:03:03  <[CoryCohen](CoryCohen)>    Automatic link dependency generation using nm. 
09:03:23  <Greg_Noel>    Yeah, that's on my queue to answer after the bug party. 
09:03:33  <[CoryCohen](CoryCohen)>    Ok.  I'll be patient then. :-) 
09:03:46  <Greg_Noel>    You probably have the scanner attached at the wrong place. 
09:03:52  <stevenknight> my initial reaction:  +1 
09:03:53  <[CoryCohen](CoryCohen)>    You guys have got plenty to do today it looks like. 
09:04:16  <Greg_Noel>    But no quorum yet 
09:04:29  <stevenknight> i think you're just not setting up the scanner quite right 
09:04:41  <stevenknight> scanning generated files works just fine for things like generated .h files 
09:04:52  <stevenknight> but it can be a little non-obvious how to do it 
09:04:56  <[CoryCohen](CoryCohen)>    That's likely.  I just started using SCons. 
09:05:07  <stevenknight> in principle scanning objects should be like scanning generated .h files 
09:06:27  <[CoryCohen](CoryCohen)>    How much more is there to it then: linkscan = Scanner(function=mylinkscan, skeys=['.o']) 
09:06:38  <[CoryCohen](CoryCohen)>    env.Append(SCANNERS=linkscan) 
09:08:20  <stevenknight> you also have to hook it up to the specific Builder involved 
09:08:38  <stevenknight> scanning for dependencies is not purely a function of the source file type (i.e., the .o suffix) 
09:08:54  <[CoryCohen](CoryCohen)>    Oh... The example had a Command builder, but I didn't think that was relevant. 
09:08:54  <stevenknight> it's always done within the context of a specific target file that's being generated 
09:09:14  <[CoryCohen](CoryCohen)>    Is there some magic I use to get the default object builder? 
09:09:18  <stevenknight> the dependencies that you generate from a .o file are appropriate for linking into an executable 
09:09:26  <[CoryCohen](CoryCohen)>    Yes. 
09:09:34  <stevenknight> but they'd be different if you were doing something else with the .o file 
09:09:47  <[CoryCohen](CoryCohen)>    (nods) 
09:09:53  <stevenknight> yeah, "magic" is right... 
09:10:12  <stevenknight> it's not something that's as easily configurable as it should be 
09:10:48  <stevenknight> hang on a sec... looking... 
09:10:53  <[CoryCohen](CoryCohen)>    Ok. 
09:12:06  <stevenknight> in Tool/<ins>init</ins>.py, there are create{Prog,[StaticLib](StaticLib),[SharedLib](SharedLib),Object}Builder() functions 
09:12:23  <stevenknight> that create the default builders for those types of things 
09:12:38  <stevenknight> you can grep in Tool/*.py for examples of different tool modules that use them to add additional things 
09:12:56  <[CoryCohen](CoryCohen)>    Great.  Thanks. 
09:13:01  <stevenknight> suffixes, emitters, etc. 
09:13:20  <stevenknight> there may be some additional surgery required, but keep asking when you get blocked 
09:13:36  <stevenknight> Greg:  looks like it might be me and you again 
09:13:45  <Greg_Noel>    Yeah 
09:13:49  <stevenknight> shall we get started? 
09:14:00  <Greg_Noel>    I only have one new point after last time 
09:14:17  <stevenknight> ?new point 
09:14:44  <Greg_Noel>    I was going over the issues and I noticed that 1872 was submitted by David 
09:15:24  <Greg_Noel>    I hadn't noticed that the first time 
09:15:41  <Greg_Noel>    With that the case, I propose to give it to him 
09:15:53  <stevenknight> +1 
09:16:19  <Greg_Noel>    Then as far as I know, there's nothing that we didn't discuss last time 
09:16:29  <stevenknight> i was scanning editlist2008 before and had one change of heart 
09:16:38  <Greg_Noel>    Which? 
09:16:48  <stevenknight> Bill's argument that we add the [BuildDir](BuildDir)() deprecation warning for 1.0 makes sense to me 
09:17:09  <stevenknight> that's #1906 
09:17:22  <Greg_Noel>    I think it's too soon 
09:17:42  <stevenknight> for just a warning? 
09:18:12  <Greg_Noel>    Well, I don't use it, so I won't fight it, but ... 
09:18:31  <Greg_Noel>    ... those that do could be annoyed. 
09:18:57  <stevenknight> true 
09:19:23  <stevenknight> but they'll be annoyed when it happens in 1.x, too 
09:19:25  <Greg_Noel>    Given that it's so misunderstood, how many users do you think it has? 
09:19:40  <stevenknight> excellent question 
09:19:57  <HM2>  Can anyone tell me how I can get scons to activate SConstruct files in subdirectories? 
09:20:01  <stevenknight> probably fairly common 
09:20:13  <Greg_Noel>    Then they need time to switch. 
09:20:16  <stevenknight> HM2:  hang on a sec while we finish this thread 
09:20:30  <HM2>  k.. 
09:21:11  <stevenknight> how much time? 
09:21:20  <Greg_Noel>    There have been deprecation warnings for Copy() ==> Clone() for a year 
09:21:45  <Greg_Noel>    I don't think it really needs more than a few months, but 1.1 sounds reasonable. 
09:22:52  <Greg_Noel>    (See, I think there will be a 1.1.) 
09:23:09  <stevenknight> guess I can live with that, provided our "THIS WILL CHANGE" warnings in the doc are prominent enough 
09:23:10  <stevenknight> are they? 
09:23:19  <stevenknight> agree re: there being a likely 1.1 
09:23:46  <Greg_Noel>    I think you need the BIG CAPS, but yes; I certainly see them. 
09:24:06  <Greg_Noel>    ... but then, I'm a reader, I actually _see_ what's in the print. 
09:24:30  <stevenknight> that definitely differentiates you from the great mass of us who mostly just skim...  :-) 
09:24:34  <[CoryCohen](CoryCohen)>    It is two rather small sentences. 
09:25:14  <stevenknight> [CoryCohen](CoryCohen):  good point 
09:25:43  <stevenknight> so let's leave 1906 for 1.x 
09:25:59  <stevenknight> but add another item for 0.98.1 to enhance the warnings in the doc: 
09:26:08  <Greg_Noel>    I actually like the schedule that's in the wiki... 
09:26:13  <stevenknight> indented "IMPORTANT NOTE:" block quotes or something 
09:26:26  <Greg_Noel>    ... one release with a doc warning 
09:26:47  <Greg_Noel>    ... one release with a compile warning that can be turned off 
09:26:54  <Greg_Noel>    ... one release with a compile warning that can't be turned off 
09:27:14  <Greg_Noel>    ... one release with a fatal error 
09:27:48  <Greg_Noel>    The block quote for emphasis sounds reasonable 
09:28:01  <stevenknight> where "one release" is a major (x.y) release, not something like 0.98.1, yes? 
09:28:18  <Greg_Noel>    That's minor release, but yes 
09:28:32  <stevenknight> okay 
09:28:58  <stevenknight> so i'll open a 0.98.1 issue to add block quotes 
09:29:06  <stevenknight> and 1906 is 1.x 
09:29:46  <Greg_Noel>    Remember, we were figuring a new release, whether major or minor, three to four times a year, so three to four months each 
09:30:13  <stevenknight> so minimum case that's about a year of lead time 
09:30:15  <stevenknight> should be reasonable 
09:32:02  <stevenknight> HM2:  SConstruct files in subdirectories 
09:32:08  <stevenknight> there's nothing magic about the file name 'SConscript' 
09:32:21  <stevenknight> you should be able to just put 
09:32:28  <stevenknight> SConscript("subdir/SConstruct") 
09:32:36  <HM2>  ...right 
09:32:39  <stevenknight> in any file and it will read up the subsidiary 
09:32:47  <HM2>  well atm i'm still trying to get a seperate builddir 
09:33:44  <stevenknight> the tricky part with subsidiary SConstruct files is the .sconsign files that store the build information 
09:34:22  <stevenknight> separate builddir:  do you mean a separate build variant, or a directory in which you want to stick all your object files from across the project? 
09:34:28  <HM2>  is SConstruct == SConscript? 
09:34:58  <stevenknight> all SCons config files are just Python scripts that get executed to set up the dependencies and stuff 
09:35:00  <HM2>  well ideally i'd like to have src/some/random/path mimicked in both build/some/random/path and include/some/random/path 
09:35:16  <stevenknight> the only magic name is SConstruct, which we use as the top level of the build 
09:35:26  <stevenknight> everything else is just convention 
09:35:41  <stevenknight> you include them in the build by calling SConscript(), but they can be named anything 
09:36:08  <HM2>  ;( 
09:37:08  <Greg_Noel>    HM2, builddir doesn't do dual mimicry 
09:37:40  <stevenknight> actually it does (or is supposed to); what would the mimicked include/some/random/path be used for? 
09:38:10  <stevenknight> if it doesn't have any actual built targets then SCons may not "realize" that you intend files to physically show up there 
09:38:30  <Greg_Noel>    To construct the install tree; we've been at this point before 
09:38:38  <HM2>  hmm 
09:38:54  <HM2>  this is odd 
09:39:11  <stevenknight> ???  oh, discusing this before I showed up? 
09:39:19  <Greg_Noel>    What builddir does is create a virtual copy of the source tree so you can build a variant in it. 
09:39:27  <HM2>  i use env = Environment (CPPPATH = 'include' in my "src" dir and it builds fine...include is ../include relative to "src" 
09:39:50  <HM2>  but with a build dir it expects to find build/include 
09:40:09  <Greg_Noel>    No, we've been 'round it on the mailing list; that's what (forgot name) really wants from builddir when he says it doesn't work like it should 
09:41:04  <stevenknight> okay, I thought this might have been a quick question to handle 
09:41:11  <stevenknight> but it sounds like we need to go into more depth 
09:41:19  <stevenknight> didn't mean to derail the bug dicussion to this extent 
09:41:21  <HM2>  scons doesn't correct include paths when it uses a build dir? 
09:41:41  <Greg_Noel>    HM2, if you made an exact copy of the source, then built in it, that's what you'd expect. 
09:42:00  <stevenknight> Greg's exactly right 
09:42:06  <HM2>  ah it builds! 
09:42:22  <HM2>  at last some sanity 
09:42:30  <Greg_Noel>    no quorum, why not? 
09:42:50  <stevenknight> hmm, that might be the first time I've heard "sanity" used in a discussion of [BuildDir](BuildDir)()...  :-) 
09:42:57  <Greg_Noel>    concur! 
09:43:12  <HM2>  and it didn't copy my source files! 
09:43:13  <HM2>  wowza 
09:43:24  <stevenknight> HM2:  you're using duplicate=0? 
09:43:28  <HM2>  yes 
09:43:34  <stevenknight> yeah, that's the way it should work, then 
09:44:01  <HM2>  right, 1 more question, how can I get it to pass multiple source files to gcc (or the compiler) at once 
09:44:10  <HM2>  possibly? 
09:44:13  <stevenknight> ah, batch builders...! 
09:44:14  <HM2>  with Object()? 
09:44:20  <Greg_Noel>    can't, see issue 1086 
09:44:26  <stevenknight> yes 
09:44:42  <stevenknight> you'd have to basically do your own custom Builder or Command right now 
09:45:18  <stevenknight> we're discussing how to extend our model to support it more naturally 
09:45:34  <HM2>  I see 
09:45:50  <HM2>  doesn't python support nested lists? seems the obvious way to do it 
09:46:05  <stevenknight> you can pretty easily set up a custom Builder of command line that uses $SOURCES to get more than one source file on the command line 
09:46:06  <Greg_Noel>    ah, er, um, Java 
09:46:08  *      [JimRandall](JimRandall) (n=[jim@](mailto:jim@ has joined #scons 
09:46:22  <Greg_Noel>    [JimRandall](JimRandall), you're late.... 
09:46:24  <stevenknight> the trick is that SCons won't (by default) realize that multiple .o files get created from it 
09:46:51  <[JimRandall](JimRandall)>   Indeed - better late than never :) 
09:47:00  <stevenknight> but Jim's here!  better than some others... 
09:47:05  <stevenknight> yes 
09:47:17  <Greg_Noel>    No quorum, so we've been chatting... 
09:47:36  <HM2>  stevenknight : no i mean multiple .c files into one .o file 
09:47:44  <Greg_Noel>    Does three constitute a quorum? 
09:47:57  <stevenknight> most substantive decision so far has been to *not* enable deprecation warnings for [BuildDir](BuildDir) until 1.x 
09:48:15  <stevenknight> but for 0.98.1 enhance the warnings in the doc with caps or block quotes 
09:48:27  <[JimRandall](JimRandall)>   And maybe a few large arrows 
09:48:28  <stevenknight> I'd say three is sufficient 
09:48:28  <Greg_Noel>    (both) 
09:48:54  <[JimRandall](JimRandall)>   Thought I don't use it, so I'd not notice it anyway :) 
09:48:59  <stevenknight> if we keep postponing things waiting for enough people to participate, it'll never happen 
09:49:18  <Greg_Noel>    true, shall we start? 
09:49:32  <stevenknight> yes, let's create the momentum and let others catch up to the train 
09:49:50  <stevenknight> once they realize we're making all sorts of decisions they disagree with...  :-) 
09:50:10  <Greg_Noel>    ok, 449? (shudder) 
09:50:37  <stevenknight> HM2:  your best bet right now for multiple .c files into one .o file is to do a custom Command() 
09:50:44  <stevenknight> yes, 449: 
09:51:08  <Greg_Noel>    I have to admit I don't understand it 
09:51:16  <Greg_Noel>    Gary was carrying this ball 
09:51:41  <stevenknight> 449:  future, p3, put gary's name on it 
09:51:45  <Greg_Noel>    done 
09:51:53  <stevenknight> if it languishes it's because there isn't enough demand anyway 
09:52:03  <Greg_Noel>    468? 
09:52:03  <[JimRandall](JimRandall)>   aye - doesn't seem that critical 
09:52:22  <stevenknight> 468:  how about turning this into a doc issue? 
09:52:33  <Greg_Noel>    hmmm... possible 
09:52:34  <stevenknight> just show people how to use atexit for this pattern? 
09:52:45  <Greg_Noel>    yes, I like it.  done 
09:52:50  <[JimRandall](JimRandall)>   Aye 
09:52:51  <Greg_Noel>    when? 
09:53:05  <stevenknight> 1.0 
09:53:13  <stevenknight> with all the other User's Guide things 
09:53:24  <Greg_Noel>    ok, I'll make it yours. 
09:53:28  <stevenknight> anything that we can't actually finish by then will get promoted en masse to 1. 
09:53:29  <stevenknight> 1.x 
09:53:33  <stevenknight> yes, mine 
09:54:05  <Greg_Noel>    505, future.  _far_ future. 
09:54:13  <stevenknight> skip 484? 
09:54:31  <Greg_Noel>    oops 
09:54:42  <stevenknight> 484:  1.x, but I'm not sure who 
09:55:09  <stevenknight> might as well be me if there's no one else obvious 
09:55:14  <Greg_Noel>    I'd do it, but I've never hacked that area 
09:55:49  <stevenknight> yeah, and it's one of those tool-incompatibility things that's really easy to fix for one and break others without knowing it... :-/ 
09:55:51  <Greg_Noel>    I can certainly add a note to explain the problem more clearly; that might make it easier. 
09:56:01  <HM2>  scons -c doesn't kill empty directories in the build directory then? 
09:56:06  <HM2>  even though it creates them 
09:56:24  <Greg_Noel>    HM2, nope, not as a rule.  unfortunately. 
09:56:25  <stevenknight> HM2:  correct, no one's come up with code to do it 
09:57:01  <Greg_Noel>    does that work for 484? 
09:57:04  <stevenknight> HM2:  it's hard to know when a directory is a build by-product vs. something that people intend to leave there 
09:57:05  <HM2>  odly i'm now getting /build/build/geometry  
09:57:25  <Greg_Noel>    Take the 'builddir' out of your subdirs. 
09:57:33  <HM2>  i see 
09:57:43  <stevenknight> 484:  1.x, P3, assign to me, add the note you were talking about 
09:57:48  <Greg_Noel>    done 
09:57:58  <Greg_Noel>    next 505> 
09:58:06  <stevenknight> 505:  i don't think it's that far off 
09:58:42  <stevenknight> and, honestly, it bugs me that waf makes a big deal of having it 
09:58:47  <Greg_Noel>    I just see no reason for it, but then, I've used stone-age tools since the stone age 
09:58:56  <HM2>  aweosme 
09:59:00  <HM2>  this is working well 
09:59:14  <stevenknight> HM2:  cool, glad to hear it 
09:59:26  <stevenknight> HM2:  a little tricky to get set up, but it's slick once everything's in place 
09:59:44  *      HM2 now has to play with install() ? 
09:59:47  <Greg_Noel>    Jim, an opinion?  I'll not stand in the way. 
09:59:54  <stevenknight> the build log part of 505 becomes really necessary for continuous integration systems 
09:59:59  <[JimRandall](JimRandall)>   I'm a monochrome kind of guy myself 
10:00:16  <[JimRandall](JimRandall)>   Though I seem to be in the minority there too :) 
10:00:18  <stevenknight> how about splitting 505? 
10:00:44  <Greg_Noel>    how? 
10:01:00  <stevenknight> i can see the color being a nice-to-have, but logging is downright useful 
10:01:21  <stevenknight> i guess I don't want to see the latter get pushed out because we're iffy about colorizing output 
10:01:28  <[JimRandall](JimRandall)>   Agreed - logging was one of the very first things I bolted on top of scons 
10:01:51  <stevenknight> how about give it me and mark it research? 
10:01:56  <Greg_Noel>    Being a UNIX guy, I just use tee. 
10:02:12  <stevenknight> can't just use tee in a continuous integration system like Buildbot or Pulse 
10:02:14  <Greg_Noel>    ok, done, research, steven 
10:02:32  <Greg_Noel>    Er, I do, works fine. 
10:02:53  <stevenknight> ??? 
10:03:09  <stevenknight> oh, i get it 
10:03:16  <Greg_Noel>    trust me, more than one way to skin a cat 
10:03:35  <stevenknight> sorry, i'm thinking of using it in conjunction with -j 
10:03:47  <stevenknight> intermixed error messages 
10:03:59  <Greg_Noel>    different problem 
10:03:59  <[JimRandall](JimRandall)>   Now that would be an interesting use of colourization too 
10:04:09  <stevenknight> yeah, you're right, i'm getting them mixed up 
10:04:29  <stevenknight> i was thinking of it as a -j issue because the only time i use it is in buidlbot 
10:04:48  <stevenknight> sorry, i've taken us down a rathole again... 
10:04:53  <stevenknight> 513? 
10:05:24  <Greg_Noel>    I think the whole issue of suffixes needs work, but it may not be this issue. 
10:05:55  <stevenknight> agreed 
10:06:05  <stevenknight> i've taken a run at this once or twice but never got far enough 
10:07:02  <Greg_Noel>    I suspect this one needs to be closed and a new issue opened that's more focused. 
10:07:12  <stevenknight> it's really dumb, though, that other suffixes can be configure and this one can't 
10:07:46  <Greg_Noel>    (they can?) 
10:07:59  <stevenknight> i believe so... 
10:08:11  <Greg_Noel>    hmmm... 
10:08:11  <stevenknight> we do support the following variables: 
10:09:20  <HM2>  I presume to pass environment junk to SConscript()'d files I need to export or something? 
10:09:23  <stevenknight> now i don't remember why I didn't "just solve" this if other languages have a working pattern to copy 
10:09:33  <HM2>  to the environment 
10:09:57  <stevenknight> HM2:  yes, check out the Export() function or the export= argument to SConscript() 
10:10:09  <stevenknight> HM2:  and Import() on the SConscript side 
10:11:08  <Greg_Noel>    I guess I don't know how those work, but I thought it required loading a Tool, and we already load too many of them. 
10:11:31  <stevenknight> back to 513:  give it to me, 2.x, p2 
10:11:38  <Greg_Noel>    It's that part that I think needs significant speedup. 
10:11:45  <Greg_Noel>    ok, done; next? 
10:11:48  <stevenknight> agreed re: speedup 
10:11:57  <stevenknight> it shouldn't require a new tool, just making the existing one smarter 
10:12:21  <Greg_Noel>    And maybe some way to configure it _without_ loading all the Tools. 
10:12:36  <stevenknight> 555:  this is less crucial with Anatoly's scons.bat fix 
10:12:43  <HM2>  I am very very impressed 
10:12:46  <stevenknight> (agree re: configuration without loading more tools) 
10:13:06  <Greg_Noel>    555, not of interest to a UNIX guy ;-} 
10:13:11  <stevenknight> :-) 
10:13:26  <HM2>  no annoying MACRO_LANGUAGE_GARBAGE, Scons seems clean 
10:13:39  <stevenknight> now that we scons.bat is smarter, 555 should just be part of overall Windows installation fixing 
10:13:48  <Greg_Noel>    pick your poison on it; I'll go along 
10:13:49  <[JimRandall](JimRandall)>   sounds good 
10:14:03  <stevenknight> let's just close this one, the Windows installation is recorded elsewhere 
10:14:19  <stevenknight> FIXED by the scons.bat change, dup it to the one I just integrated 
10:14:27  <stevenknight> let me get a number for you... 
10:15:18  <stevenknight> 555 is dup 1882 
10:15:40  <stevenknight> 561: 
10:15:44  <Greg_Noel>    typing ahead, 561 said CVS('subdir/file') 
10:16:13  <Greg_Noel>    rather than 'CVS(.)' n the subdir 
10:16:25  <Greg_Noel>    oops, modulo quoting 
10:16:26  <stevenknight> ah!  okay, i get it 
10:16:28  <stevenknight> INVALID 
10:16:31  <Greg_Noel>    done 
10:16:52  <stevenknight> 633:  windows installation 
10:16:53  <Greg_Noel>    skip 646 
10:17:19  <Greg_Noel>    oops, I'm off again. 
10:17:51  <Greg_Noel>    yes, defer until we know about GSoC project 
10:17:58  <stevenknight> agreed 
10:18:49  <Greg_Noel>    646 
10:19:04  <Greg_Noel>    (been so long I've forgotten this) 
10:19:34  <stevenknight> 646:  2.x, me, p3 
10:19:57  <stevenknight> we're just not consistent about how we do this searching-for-tools thing 
10:20:25  <Greg_Noel>    I'll add a note to it; should be possible with Dir('bin') 
10:20:47  <Greg_Noel>    648 
10:20:48  <stevenknight> okay, cool 
10:21:23  <stevenknight> 648:  I agree with you:  1.x, p4 
10:21:23  <Greg_Noel>    DOS, ick. 
10:21:33  <[JimRandall](JimRandall)>   648 not too hard to do, and would be handy 
10:21:48  <[JimRandall](JimRandall)>   Can send that one to me. 
10:21:54  <stevenknight> Jim, you interested?  If not, I might be able to look at it as part of.. 
10:21:54  <Greg_Noel>    done, both 
10:21:55  <stevenknight> okay... 
10:22:06  <stevenknight> 659: 
10:22:50  <stevenknight> more windows command line, Jim you okay with taking this one too? 
10:23:09  <[JimRandall](JimRandall)>   Aye, that windows? 
10:23:15  *      bdbaddog2007 (n=[]( has joined #scons 
10:23:27  <stevenknight> Bill! 
10:23:33  <Greg_Noel>    Stylishly late? 
10:23:43  <stevenknight> we gave you lots and lots and LOTS of action items... :-) 
10:23:53  <[CoryCohen](CoryCohen)>    Sorry, bit late here... 659 works just fine for me. 
10:23:57  <bdbaddog2007> G'morning.. Yes weekend mornings are difficult for me. 
10:24:32  <stevenknight> [CoryCohen](CoryCohen):  are you under Cygwin? 
10:24:36  <[CoryCohen](CoryCohen)>    Windows, cygwin, cut-and-pasted the test case. 
10:24:37  <Greg_Noel>    So it's fixed now, by something other that us? 
10:24:44  <stevenknight> no, i don't think it's fixed 
10:25:02  <[CoryCohen](CoryCohen)>    The shell should not care about the space (or lack thereof). 
10:25:05  <stevenknight> under cygwin you're using their UNIX-shell derivative 
10:25:14  <[CoryCohen](CoryCohen)>    I'm deeply suspicious of a not-real bash shell. 
10:25:17  <stevenknight> i think this is about using Windows' cmd.exe 
10:25:43  <[CoryCohen](CoryCohen)>    Yeah.  That's mote likely, but the reporter appears to have ls, etc. 
10:26:09  <stevenknight> ah, true 
10:26:15  <stevenknight> maybe it *is* fixed then... 
10:26:25  <[CoryCohen](CoryCohen)>    Not that I'm against fixing it, but I think it's the shell that broken. 
10:26:25  <stevenknight> hang, on, let me boot up my Windows laptop 
10:26:34  <[JimRandall](JimRandall)>   Agreed - it doesn't run under plain vanilla windows 
10:26:34  <stevenknight> i'll test it on a non-Cygwin system while we move on 
10:26:51  <[CoryCohen](CoryCohen)>    Ok. 
10:26:54  <[JimRandall](JimRandall)>   the /dev/null 
10:27:08  <[JimRandall](JimRandall)>   It can't find that file for some reason :) 
10:28:08  <Greg_Noel>    695: I'm not sure get_contents is the right API to expose 
10:28:21  <stevenknight> 662:  dup 1882 
10:28:42  <stevenknight> 695:  agree w/Greg 
10:28:49  <Greg_Noel>    662: done 
10:29:35  <stevenknight> 695:  I'd prefer to expose something called read() so it looks like a Python file handle 
10:29:56  <bdbaddog2007> should we just make a note on the bug, and open a feature request bug with what you want to do for 2.x ? 
10:30:05  <stevenknight> sounds good 
10:30:07  <bdbaddog2007> 695 that is, and close it ? 
10:30:28  <Greg_Noel>    ok, done (but note that Value already has read) 
10:31:04  <Greg_Noel>    720 
10:31:57  <Greg_Noel>    Ah, I think you're right about Rob; Mark Flacy for Java. 
10:32:52  <stevenknight> 659:  it works even under vanilla Windoze 
10:32:55  <stevenknight> FIXED 
10:33:04  <stevenknight> 720:  agree re: Rob 
10:33:16  <stevenknight> and Mark (if he's interested) 
10:33:45  <stevenknight> Greg, would you either approach them yourself, or be a burr under my saddle for me to do it? 
10:33:52  <Greg_Noel>    I'll write them. 
10:33:55  <stevenknight> I suck at staying on-task with that sort of things... 
10:34:11  <Greg_Noel>    Me, too, but I have a nag list... 
10:34:28  <stevenknight> okay, on to 2008? 
10:34:34  <Greg_Noel>    I'll also ask Rob if he thinks it's fixed. 
10:34:39  <Greg_Noel>    yes, 2008 
10:34:40  <stevenknight> cool 
10:35:06  <Greg_Noel>    1872 
10:35:16  <stevenknight> 1872:  consensus 2.x, p2 
10:35:27  <Greg_Noel>    I noticed this was from David, so I recanted. 
10:36:02  <stevenknight> meaning you're okay with that consensus? 
10:36:28  <Greg_Noel>    No, I originally suggested 2.x; I recanted and now suggest 1.x. 
10:36:44  <stevenknight> oh, I see 
10:36:57  <Greg_Noel>    I'm still ok with 2.x, but if we're giving David things to do... 
10:37:34  <Greg_Noel>    Why not 2.x and ask him if he thinks it can be 1.x? 
10:37:41  <stevenknight> sure, if he's up for it.  1.x.  worst that happens is we end up pushing it out 
10:37:46  <stevenknight> i'd say go the other way 
10:37:52  <Greg_Noel>    ok, done. 
10:37:58  <stevenknight> make sure we at least consider it for 1.x and push out if need be 
10:38:10  <stevenknight> instead of having things on the 2.x list that we don't consider pulling in 
10:38:46  <Greg_Noel>    1873 
10:38:56  <stevenknight> 1873:  1.x, p2 
10:39:07  <Greg_Noel>    Ouch.  You sure? 
10:39:23  <stevenknight> i think trying to do something more friendly with this stuff sooner rather than later is important 
10:39:29  <Greg_Noel>    ok, done. 
10:39:43  <stevenknight> not sure if it wil actually make it by then, but we should try 
10:40:03  <Greg_Noel>    1874 
10:40:07  <bdbaddog2007> :) 
10:40:17  <bdbaddog2007> I'm not sure my bug report on this one captured the issue. 
10:40:26  *      ita (n=[]( has joined #scons 
10:40:48  <Greg_Noel>    yes, it did.  I just don't see any general solution. 
10:40:55  <stevenknight> right 
10:41:11  <bdbaddog2007> I link a binary against, which needs to be installed in a directory which is the LIBPATH, scons doesn't install it prior to the link so link fails. 
10:41:15  <Greg_Noel>    How can you tell when the dot is a suffix or part of the name. 
10:41:20  <stevenknight> always adding the suffix is wrong for some configurations.  not adding the suffix is wrong for some configurations 
10:41:40  <bdbaddog2007> this is specifically for shared library names. 
10:42:13  <Greg_Noel>    Well, is it the same for .dylib?  .pylib?  .dll? 
10:42:30  <Greg_Noel>    Too many variations. 
10:42:48  <bdbaddog2007> this is for shared libraries found by findlib 
10:43:16  <bdbaddog2007> where it trys a number of name variations. 
10:43:30  <bdbaddog2007> with and without suffix, but in this case doesn't try suffix. 
10:44:20  <Greg_Noel>    Does the workaround work? 
10:45:11  <stevenknight> oh, okay, so this is in Scanner/, yes? 
10:45:31  <bdbaddog2007> hold on lemme bring up the file. 
10:45:51  <bdbaddog2007> actually if you want we can defer this bug til later. 
10:46:09  <stevenknight> yeah, i found it 
10:46:11  <Greg_Noel>    yes, table, discuss in mailing list. 
10:46:26  <stevenknight> it's a real bug 
10:46:41  <stevenknight> table and discuss 
10:46:53  <Greg_Noel>    1897, dup, three agreed 
10:47:12  <stevenknight> you mean 1879, yes? 
10:47:14  <bdbaddog2007> 1879 right? 
10:47:32  <Greg_Noel>    sigh, dyslexia... 
10:47:53  <stevenknight> dyslexics of the world untie! 
10:48:14  <stevenknight> (I get to say that because both my wife and daughter are...) 
10:48:31  <Greg_Noel>    makes sense to me... 
10:48:36  <stevenknight> 1880: 
10:49:00  <stevenknight> 1880:  2.x, drop it even to p4? 
10:49:02  <Greg_Noel>    Didn't Gary also report a 1880-ish issue? 
10:49:22  <stevenknight> this is the sort of thing Benoit is really good at tracking down 
10:49:38  <Greg_Noel>    good idea, I'll ask him.  Next? 
10:50:00  <stevenknight> 1883:  much less an issue with the scons.bat patch 
10:50:35  <stevenknight> i'd like to put it under the general windows installation umbrella 
10:50:43  <Greg_Noel>    works for me 
10:50:46  <stevenknight> however we decide to actually record that... 
10:51:18  <bdbaddog2007> wiki page? or a  bug which depends on other bugs ? 
10:51:24  <Greg_Noel>    Why don't I create a keyword? 
10:51:30  <bdbaddog2007> I usually like the bug which depends on other bugs.. 
10:51:49  <stevenknight> i like both the keyword and the umbrella bug 
10:51:59  <bdbaddog2007> even better.. 
10:52:00  <bdbaddog2007> :) 
10:52:01  <Greg_Noel>    ok, I'll work something up 
10:52:04  <Greg_Noel>    next? 
10:52:05  <stevenknight> thanks 
10:52:35  <stevenknight> 1885:  see if Rob Managan will take it? 
10:52:39  <Greg_Noel>    I'll ask Rob 
10:52:44  <stevenknight> done 
10:52:46  <Greg_Noel>    next 
10:53:37  <stevenknight> 1889:  consensus research 
10:53:41  <Greg_Noel>    we've been seeing a bunch of these lately; there was another on the mailing list day before yesterday. 
10:53:50  <bdbaddog2007> yes saw that. 
10:53:58  <Greg_Noel>    research, who? 
10:54:15  <stevenknight> Jim, you had some exposure to the problem...? 
10:54:19  <[JimRandall](JimRandall)>   Aye - it bit me 
10:54:28  <[JimRandall](JimRandall)>   Tried to create a reproducible case, but had a hard time 
10:54:35  <bdbaddog2007> would this be related to the other bug dealing with caching and the contents of a directory changing? 
10:54:37  <[JimRandall](JimRandall)>   seems to be because boost/algorithm (a directory) 
10:54:59  <[JimRandall](JimRandall)>   has a file that refers to the C++ STL file algorithm 
10:55:17  <[JimRandall](JimRandall)>   So possibly a saved result in a .sconsign causing trouble 
10:55:23  <[JimRandall](JimRandall)>   or a scanner issue? 
10:55:28  <stevenknight> hmm, that might be enough to go on 
10:55:30  <stevenknight> probably scanner 
10:55:39  <stevenknight> put my name on it, leave it research 
10:55:46  <Greg_Noel>    done, next? 
10:56:01  <stevenknight> 1891:  me, research, p3 
10:56:13  <stevenknight> i'm taking a fresh look at the windows support in general 
10:56:21  <Greg_Noel>    ok, done, next? 
10:56:22  <nano->        Sorry to bounce in with an OT question. Is there any way to get a list of tools intialized, and their corresponding classes, so you can call exists() from a Configure check. 
10:57:15  <Greg_Noel>    1894, future, three votes 
10:57:36  <stevenknight> nano-:  calling env.Tool() on each tool in your list? 
10:57:51  <stevenknight> 1894:  done 
10:58:20  <Greg_Noel>    skip 1896 
10:58:22  <stevenknight> 1895:  i'd say research, gary (overall toolchain refactor) 
10:58:28  <nano->        stevenknight: Huh.. it does? I tried adding a print, but it was at least hidden. 
10:58:42  <nano->        stevenknight: Also, no matter what that method returns, the tool is still generated.  
10:58:53  <stevenknight> nano-:  not sure I understand your original question 
10:59:30  <stevenknight> nano-:  oh, you mean just get the list of Tool modules *without* having them call generate()? 
10:59:33  <nano->        stevenknight: Well, my original question was to get env.Configure to check if my tools exist, so I wanted to get hold on the tools so that I could access their .exists methods.  
10:59:50  <nano->        Because tools are loaded even if their executables aren't found.  
11:00:53  <nano->        So lets say I have env.Detect(foo) in my exists(env) in my tool, and it returns None, (or whatever) SCons still generates the tool.  
11:00:55  <Greg_Noel>    1895, not sure it's toolchain.  Sounds like Detect() 
11:01:23  <stevenknight> nano-:  no good public API for doing what you want 
11:01:58  <stevenknight> nano-:  look in Tool/<ins>init</ins>.py for things that might get you close 
11:02:10  <nano->        So what's the reason for exists() in Tools anyway? As it doesn't seem to matter what it does. 
11:02:31  <stevenknight> nano-:  specifically things like Findtool(), [FindAllTools](FindAllTools)() 
11:02:55  <stevenknight> nano-:  exists() is used by the default search, but the presumption is if you call env.Tool() you're specifically asking to have the module applied 
11:03:32  <Greg_Noel>    1895, put on Gary's plate to research? 
11:03:39  <stevenknight> Greg_Noel:  1895, gary, research 
11:03:41  <nano->        Yeah, but env.Tool() will fail if the executables aren't found? 
11:03:47  <Greg_Noel>    done 
11:03:50  <nano->        Not that I've noticed.  
11:04:17  <nano->        Oh, nevermind.. go on with your bug talks instead of this one.  
11:04:25  <stevenknight> 1896:  skip, alrady integrated 
11:04:26  <Greg_Noel>    1900 
11:04:57  <Greg_Noel>    where is the intel() tool used? 
11:05:14  <ita>  stevenknight: is the great signature refactoring complete? 
11:06:25  <Greg_Noel>    Sigh.  Should we just stop?  We're getting more interruptions than work done. 
11:06:30  <stevenknight> 1900:  not sure, this strikes me as another gary research 
11:06:59  <stevenknight> Greg_Noel:  yeah, we should stop -- i have to peel off soon anyway 
11:07:03  <stevenknight> ita:  hey Thomas 
11:07:13  <Greg_Noel>    ok, I'll put it on his plate. 
11:07:14  <stevenknight> yes, the signature refactoring was released in 0.98.0 
11:07:35  <stevenknight> "complete" is a relative word...  :-) 
11:07:36  <Greg_Noel>    1901, done. 
11:07:49  <ita>  stevenknight: ok, thanks 
11:08:03  <stevenknight> some side effects are still turning up, but they're in increasingly obscure corner cases 
11:09:22  <Greg_Noel>    1904, I think this just showed up in the wiki; what to do with it otherwise? 
11:10:37  <Greg_Noel>    future, what priority? 
11:11:03  <bdbaddog2007> if he can get some test together could we pull it in? shouldn't impact anything else right? 
11:12:07  <Greg_Noel>    We lack a general framework for _any_ testing; without that, this will just change when we do. 
11:13:29  <bdbaddog2007> looks like he's just created a builder. if we treat it like a builder in the near term and address a testing framework later, would that be acceptable? 
11:13:44  <stevenknight> bdbaddog2007:  that could work 
11:14:08  <Greg_Noel>    fine with me; Bill, you want to chase it? 
11:14:20  <bdbaddog2007> sure.  
11:14:31  <[CoryCohen](CoryCohen)>    Well guys, the wife says it's time to go get some food.  Thanks for the help earlier -- I've made some progress using an emitter, but I still need help.  Rather than interrupt your bug tracking, I'll send mail to dev later today. 
11:14:39  <Greg_Noel>    ok,I'll assign it to you. 
11:14:55  <stevenknight> [CoryCohen](CoryCohen):  thanks for checking in 
11:15:10  <[CoryCohen](CoryCohen)>    It's been educational for me. :-) 
11:15:33  <[CoryCohen](CoryCohen)>    Bye! 
11:15:54  <Greg_Noel>    1905, don't know what to suggest. 
11:16:42  <bdbaddog2007> Float a message on user and dev mailing lists sugguesting retiring this and see what feedback there is? 
11:17:04  <Greg_Noel>    Works.  Who should send it?  Steven? 
11:17:15  <stevenknight> probably 
11:17:38  <Greg_Noel>    ok, you for research? 
11:17:42  *      Administrator (n=[chatzill@](mailto:chatzill@ has joined #scons 
11:17:42  <stevenknight> yeah 
11:18:01  *      Administrator is now known as Azverkan 
11:19:04  <stevenknight> 1906:  greg and i were talking about it earlier 
11:19:15  <stevenknight> our consensus was to save the deprecation warning until 1.x 
11:19:28  <stevenknight> but make the will-be-deprecated documentation much more noticeable 
11:19:36  <stevenknight> caps, bold, block quotes 
11:19:56  <stevenknight> gotta go 
11:20:02  <Greg_Noel>    One more? 
11:20:06  <bdbaddog2007> :( I still think 1.0 is the place to put it for reasons stated in spreadsheet. 
11:20:09  <stevenknight> one last:   1907 
11:20:13  <Greg_Noel>    1907? 
11:20:23  <stevenknight> i tried to integrate this morning 
11:20:35  <stevenknight> it's conflicting with another of Benoit's patches 
11:20:48  <stevenknight> I need to get info from him on how to merge the two, cause I obviously didn't do it right 
11:20:52  <Greg_Noel>    Get him to resolve them? 
11:20:56  <stevenknight> yeah 
11:21:00  <Greg_Noel>    Should I write him? 
11:21:10  <stevenknight> sure, if you could that would be helpful 
11:21:24  <Greg_Noel>    (Bill, talk to me later about 1906) 
11:21:31  <Greg_Noel>    ok, wilco. 
11:21:32  <stevenknight> okay, thanks everyone -- i'm out 
11:21:35  <bdbaddog2007> ok 
11:21:37  *      stevenknight (n=[]( has left #scons ("Leaving") 
11:22:48  <Greg_Noel>    Bill, it's just too soon for a warning.  You've got to give people time to convert. 
11:23:25  <bdbaddog2007> I thought that was the purpose of deprecation message 
11:23:36  <Greg_Noel>    The first time they'll get a release with [VariantDir](VariantDir) is probably 1.0, so that's simply too early to _nag_ them about it. 
11:23:48  <Greg_Noel>    A warning in the manual is appropriate. 
11:24:09  <Greg_Noel>    Look at, uh, []( 
11:24:44  <bdbaddog2007> Yeah I guess I can see that, but do we put warning in 2.0 release candidates then? 
11:25:17  <bdbaddog2007> 1.0.1 ? 
11:26:12  <Greg_Noel>    1.1 or 2.0 release candidates, whichever comes first. 
11:26:22  <bdbaddog2007> o.k. I see your point. 
11:26:32  <bdbaddog2007> so 1.x the deprecation then? 
11:26:41  <Greg_Noel>    yes 
11:27:32  <bdbaddog2007> o.k. sounds good. 
11:27:50  <Greg_Noel>    Um, now I'm being called for lunch; gotta go.  Cul? 
11:27:55  <bdbaddog2007> So punt until next bug party.  
11:28:08  <bdbaddog2007> I'll likely be on later.. thanks again for arranging. 
11:28:12  <Greg_Noel>    Hmmm... hang on. 
11:30:00  <bdbaddog2007> hanging.. ;) 
11:30:35  <Greg_Noel>    ok, I thought we were getting guests for lunch; turns out they're picking up my wife for a lunch with the ladies, so if I go hungry, I can stay. 
11:30:55  <[JimRandall](JimRandall)>   few things in the world worth going hungry for :) 
11:31:10  <Greg_Noel>    But this may be one.  Can you stay? 
11:31:15  <bdbaddog2007> true. sleep food water, all high on my priority lists. 
11:31:21  <[JimRandall](JimRandall)>   Aye, I can 
11:31:26  <bdbaddog2007> sure. 
11:31:46  <Greg_Noel>    Azverkan, you really there?  Or is that a bot? 
11:31:54  <Azverkan>     its me 
11:32:03  <Azverkan>     slept in cause I had to work late and missed it 
11:32:16  <Greg_Noel>    So we still have a quorum.  Everybody want to go on? 
11:32:43  <bdbaddog2007> sure. probably can go another 20 - 30 minutes. 
11:32:53  <[JimRandall](JimRandall)>   alrighty 
11:33:01  <bdbaddog2007> so 1908 then? 
11:33:35  <Greg_Noel>    yes. 
11:33:54  <Greg_Noel>    Nice idea, but I don't see use case. 
11:34:30  <[JimRandall](JimRandall)>   Where I'd use it is in helping to track down cache corruption 
11:34:47  <Greg_Noel>    Happen often? 
11:34:59  <[JimRandall](JimRandall)>   Once every couple of months or so 
11:35:09  <[JimRandall](JimRandall)>   Sometimes once a month when things get busy 
11:35:12  <[JimRandall](JimRandall)>   Still not sure why 
11:35:27  <Greg_Noel>    How big a cache?  Simple to just blow it away and recache. 
11:36:15  <[JimRandall](JimRandall)>   Not sure exact size.  Difference between cached and uncached builds is about 30-40 minutes or so, which is significant 
11:36:36  *      Mikamikem (n=[mikamike@](mailto:mikamike@ has joined #scons 
11:36:45  <Greg_Noel>    Once a month? 
11:37:04  <Mikamikem>    has anyone ever set up a sconstruct file that has multiple environments and multiple configuration contexts before? 
11:37:30  <[JimRandall](JimRandall)>   About that.  Certainly don't care enough to have implemented it myself :)    It's main feature is a "kinda nice, and has a patch there too" 
11:37:55  <Greg_Noel>    I haven't looked at it; what does the patch fix? 
11:37:56  <bdbaddog2007> I guess if the patch is there, 1.x 
11:38:23  <[JimRandall](JimRandall)>   patch implements it, I believe 
11:38:58  <Greg_Noel>    But if the problem is some timing issue, it really doesn't fix the base issue. 
11:39:06  <[JimRandall](JimRandall)>   Haven't looked at the patch myself, but Benoit usually good 
11:39:17  <bdbaddog2007> I'm looking at patch now. 
11:39:17  <[JimRandall](JimRandall)>   Agreed.   and I'd fix the base issue if I knew what it was :) 
11:39:50  <Greg_Noel>    ok, Jim you want to contact Benoit and see if he has any insight? 
11:39:50  <[JimRandall](JimRandall)>   In the not too distant future, going to restrict the machines populating the cache to see if we can make it effectively disappear 
11:40:12  <bdbaddog2007> I added a note to bug on 4/8 requesting use model. 
11:40:27  <bdbaddog2007> mark it research ? 
11:40:49  <Greg_Noel>    If it's just for debugging a real problem and has no other use, ... 
11:41:09  <Greg_Noel>    ... I'd assign it to Jim to talk to Benoit, ... 
11:41:18  <bdbaddog2007> ok sounds good. 
11:41:35  <Greg_Noel>    ... and see if we can just go to the base issue and fix the timing ... 
11:41:52  <Greg_Noel>    ... no sense to add this just to decorate the command line ... 
11:41:55  <[JimRandall](JimRandall)>   I don't know if that's what's happening for him  
11:42:11  <Greg_Noel>    ... and then remove it when debugging is done. 
11:42:15  <bdbaddog2007> so research, Jim,  and move on then? 
11:42:19  <Greg_Noel>    ok, 
11:42:54  <bdbaddog2007> 1909, is the daemon thing. future seems to be consensus? 
11:43:00  *      Paf (n=[]( has joined #scons 
11:43:18  <Greg_Noel>    yes, what priority? 
11:43:30  <Greg_Noel>    p4?  p5? 
11:43:54  <bdbaddog2007> steven sugguested p3, I'd be fine with that, could be really useful. 
11:44:42  <Greg_Noel>    ;-} I disagree with Steven; I think 'zero change' performance improvement will make these go away. 
11:44:59  <bdbaddog2007> p4 and next then? 
11:45:06  <Greg_Noel>    good-o 
11:45:32  <bdbaddog2007> 1910 seems 1.x consensus 
11:45:57  <Greg_Noel>    1910, now four votes; enough for consensus; move on? 
11:46:02  <bdbaddog2007> yup. 
11:46:34  <Greg_Noel>    1911 
11:47:01  <bdbaddog2007> I see Brandon is adding to spreadsheet just ahead of discussion.. ;) 
11:47:22  <Azverkan>     1911 sounds like we need a partial test case to resolve 
11:47:26  <Greg_Noel>    Close enough...  looks like consensus 1.x 
11:47:43  <bdbaddog2007> yes. 
11:47:54  <Greg_Noel>    Put Brandon on it?  {;-} 
11:49:11  <bdbaddog2007> sounds good to me. 
11:49:14  <bdbaddog2007> 1913 
11:49:22  <bdbaddog2007> 1.0 seems to be consensus 
11:49:41  <Greg_Noel>    done 
11:50:19  <Greg_Noel>    1914 
11:50:34  <[JimRandall](JimRandall)>   caused by subst playing fast and loose with spaces I think 
11:51:53  <[JimRandall](JimRandall)>   can "fix" is by not using subst to expand the env variable 
11:52:03  <[JimRandall](JimRandall)>   changing subst would be more involved :) 
11:52:09  <Greg_Noel>    Indeed.  If it's as simple as just fetching the env var directly... 
11:52:28  <Greg_Noel>    Jim, you interested? 
11:52:40  <[JimRandall](JimRandall)>   Sure.  Can't directly test it, as I don't have that tool chain, but can test a proxy. 
11:53:29  <bdbaddog2007> ok guys. I've gotta leave now.  
11:54:19  <Greg_Noel>    ok, I'll make it yours. 
11:54:48  <Greg_Noel>    Bill, cul. 
11:54:54  <bdbaddog2007> l8r 
11:54:58  <[JimRandall](JimRandall)>   have fun 
11:54:58  *      bdbaddog2007 has quit ("Leaving.") 
11:55:22  <Greg_Noel>    I'm losing track; who's still here? 
11:55:37  <[JimRandall](JimRandall)>   *wave* 
11:55:38  <Azverkan>     me 
11:57:34  <Greg_Noel>    1915? 
11:58:37  <Azverkan>     matching search path ordering with every compiler in existence is not possible 
11:59:04  <Azverkan>     need to support of some number of high profile ones and document differences in behavior for the rest 
11:59:34  <Greg_Noel>    Yeah, but I don't see that as a documentation bug. 
12:02:29  <Greg_Noel>    ok, Bill wants it; we'll give it to him and see what he finds.  That work? 
12:02:29  <Azverkan>     reply to submitter and ask for more info, otherwise invalid then? 
12:02:43  <Azverkan>     yep 
12:02:49  <Greg_Noel>    ok, next. 
12:03:14  <Greg_Noel>    1916, consensus 
12:03:36  <Greg_Noel>    1918, give to Steven? 
12:03:56  <[JimRandall](JimRandall)>   sounds good - hopefully is fixed. 
12:04:24  <Greg_Noel>    1920, Gary was following this, so I don't know the status. 
12:05:23  <Greg_Noel>    Steven says give it to Gary; I'll go along with that. 
12:05:40  <[JimRandall](JimRandall)>   Aye 
12:06:00  <Greg_Noel>    1.x? 
12:06:48  <[JimRandall](JimRandall)>   I guess.  I'm so the wrong person to say - not really planning on using it myself :) 
12:07:09  <Greg_Noel>    It can always be pushed.  Next? 
12:07:46  <[JimRandall](JimRandall)>   Getting to a long string of entries here that I'm not going to be much help on 
12:08:08  <Greg_Noel>    1921, invalid? 
12:08:17  <[JimRandall](JimRandall)>   aye 
12:08:54  <Azverkan>     yep 
12:09:06  <[JimRandall](JimRandall)>   And brandon's editing away there is almost like he's in the chat :) 
12:09:15  <Azverkan>     I would like to see it addressed at some point in the future but probably not before 2.x 
12:09:31  <Azverkan>     (or 3.x) 
12:09:51  <Greg_Noel>    Yeah.  Brandon, you make an interesting point about it being depends instead of dup. 
12:10:06  <[JimRandall](JimRandall)>   Azverkan == Brandon? 
12:10:12  <Azverkan>     yea 
12:10:19  <[JimRandall](JimRandall)>   aha :) 
12:10:20  <Greg_Noel>    Yeah, I initially thought it was Ken but I sussed it out. {;-} 
12:11:47  <Greg_Noel>    There's a similar FORTRAN issue later; wonder if they should be dups or depends? 
12:12:39  <Azverkan>     I come from the moz project where depends are used all the time 
12:12:56  <Azverkan>     and dups is from submitters who didn't find the bug in the db before posting 
12:13:04  <Greg_Noel>    Yeah, I agree; I'll go with that. 
12:13:52  <Greg_Noel>    I guess I just assumed that batch builder would take care of that, but it's a good point to keep them as points to check off. 
12:14:05  <Greg_Noel>    ok, depends.  next? 
12:14:16  <[JimRandall](JimRandall)>   afk a sec 
12:15:05  <Greg_Noel>    1924 now has a consensus of 1.x 
12:15:11  <Greg_Noel>    next? 
12:16:12  <Azverkan>     dont really understand what the next one is trying to solve 
12:16:23  <Greg_Noel>    1925 
12:16:37  <Azverkan>     yeah 
12:17:18  <Greg_Noel>    He wants internal names to be relative, so he can move them wholesale. 
12:17:37  <Greg_Noel>    Useful in an install tree, for example, instead of full paths. 
12:18:59  <Greg_Noel>    Create a tree in /var/tmp/prog/usr/bin that's supposed to go in /usr/bin, so it wants paths to look like ../lib/xxx 
12:19:56  <Greg_Noel>    Hold for next time, so Steven can comment? 
12:20:13  <Azverkan>     fine with me 
12:20:39  <Greg_Noel>    done 
12:21:19  <Greg_Noel>    1926, pilot error? 
12:22:18  <[JimRandall](JimRandall)>   kinda sounds like it 
12:23:08  <Greg_Noel>    I'll take it and be sure. 
12:23:59  <[JimRandall](JimRandall)>   up to 1932 seem to be all fortran, with 1.0 consensus 
12:24:12  <Greg_Noel>    1927 through 1932 have been assigned to David 
12:24:26  <Greg_Noel>    1933? 
12:25:01  <[JimRandall](JimRandall)>   marked as fixed 
12:25:15  <Greg_Noel>    Um, it seems to me I just saw it go by as fixed 
12:25:29  <Greg_Noel>    ok, next? 
12:25:40  <[JimRandall](JimRandall)>   1937 dup and fixed 
12:26:10  <Greg_Noel>    ok, next 
12:26:29  <[JimRandall](JimRandall)>   1940 future p3 consensus, and seems reasonable to me 
12:26:55  <Greg_Noel>    ok, next? 
12:27:24  <[JimRandall](JimRandall)>   1941 - future taskmasterNG, yes? 
12:27:35  <Greg_Noel>    1941 also future consensus 
12:28:07  <Greg_Noel>    uh, it may resurface before then, but yes. 
12:28:58  <Greg_Noel>    1944? 
12:29:31  <Greg_Noel>    Bill wants it; give it to him. 
12:29:43  <[JimRandall](JimRandall)>   sounds good to me 
12:30:16  <Azverkan>     yeah 
12:30:26  <Greg_Noel>    1945? 
12:30:29  <[JimRandall](JimRandall)>   1945 - part of the problem is being caused by a different bug 
12:30:55  <Greg_Noel>    which? 
12:31:32  <[JimRandall](JimRandall)>   hrm, one sec - not sure If I'm right about that 
12:32:18  <[JimRandall](JimRandall)>   in his 2nd para, why is scons complaining? 
12:33:00  <Azverkan>     which 2nd para 
12:33:02  <Azverkan>     op or ken? 
12:33:17  <[JimRandall](JimRandall)>   ken 
12:33:48  <Azverkan>     sounds like exists vs lexists mismatch? 
12:34:32  <Greg_Noel>    Are you on 1945? 
12:34:38  <[JimRandall](JimRandall)>   I thought so 
12:34:52  <[JimRandall](JimRandall)>   Seemed odd to be complaining about an implicit dependency at all 
12:35:03  <Azverkan>     err no 
12:35:29  <[JimRandall](JimRandall)>   Hrm, thought the problem I'm thinking of is different - for directories, I can see why it wouldn't be ducked 
12:36:03  <[JimRandall](JimRandall)>   Nope, I'm on the wrong track - ignore me :) 
12:36:18  <Greg_Noel>    Apparently, the directory scanner caches, but doesn't have a decider to determine when to rescan. 
12:37:30  <Greg_Noel>    If it's really that simple (and I have no idea), turning off caching for directories would indeed fix it, but make things slower unnecessarily. 
12:38:41  <Greg_Noel>    I see a lot of 1.x suggested; maybe 1.x p2?  Or p1? 
12:39:31  <[JimRandall](JimRandall)>   Aye.   Seems like it'd make it impossible to use dir scanners and implicit at the same time 
12:39:47  <Greg_Noel>    Brandon? 
12:40:01  <[JimRandall](JimRandall)>   which would effectively make dir scanners a lot less useful 
12:40:19  <Azverkan>     I haven't used implicit cache in years so no comment 
12:40:35  <Greg_Noel>    ok, 1.x p1?  Jim? 
12:40:46  <[JimRandall](JimRandall)>   Sure thing 
12:40:49  <Greg_Noel>    done 
12:41:01  <Greg_Noel>    1946, lexists? 
12:42:39  <[JimRandall](JimRandall)>   haven't read the gsoc, but punting until 2.x seems OK to me 
12:42:41  <Greg_Noel>    Unfortunately, adding symlinks is a lot of work and potentially destabilizing.  I can't see it before 2.x, and I see Brandon just made the consensus. 
12:43:36  <Greg_Noel>    1949? 
12:43:55  <Azverkan>     hold for bill 
12:44:39  <Greg_Noel>    Probably also a dependency of 1086, batch builders. 
12:44:42  <Azverkan>     I can't think of a way to do this that wouldn't require mucking with internal scons state in a post builder 
12:44:54  <Azverkan>     if Bill has found one he would be the best to comment 
12:45:04  <Greg_Noel>    ok, hold. 
12:45:13  <Azverkan>     I dont think its a batch builder related issue tho 
12:45:21  <Greg_Noel>    1950? 
12:45:48  <Greg_Noel>    Yes, batch builder must deal with circular dependencies to create best batch. 
12:47:22  <Greg_Noel>    1950, invalid.  If Bill objects, he can reopen. 
12:48:07  <[JimRandall](JimRandall)>   Aye, I missed the Builder part at first too 
12:49:08  <Greg_Noel>    Brandon, a test case for a timing issue that surfaces rarely?  Surely you jest! {;-} 
12:49:41  <Azverkan>     someone probably has an open source project somewhere that it surfaces in? 
12:50:51  <Greg_Noel>    It's Gary's bug; it obviously doesn't happen to him very often, or he'd have fixed it. 
12:53:22  <Greg_Noel>    The point about the test case is well-taken, though; I suggest we put that to Steven, as he already has a couple of test cases like that. 
12:54:04  <Azverkan>     This type of issue might be easier to track down with scons running on a non cPython version of Python 
12:54:25  <Azverkan>     not sure how to find the bug without auditing the code 
12:55:54  <[JimRandall](JimRandall)>   Sorry guys - I'm going to have to take off 
12:56:29  <[JimRandall](JimRandall)>   good luck with the triage 
12:56:39  <Greg_Noel>    Yeah, and the dog is asking for his walk; I need to go, too. 
12:56:50  <Greg_Noel>    Time to quit, I think. 
12:57:00  <Azverkan>     same 
12:57:07  <[JimRandall](JimRandall)>   have fun all 
12:57:10  <Greg_Noel>    ok, cul. 
12:57:16  <Azverkan>     later