IrcLog2008 04 12

William Deegan edited this page Jan 14, 2016 · 2 revisions
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 

Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.