Clone wiki

SCons / BugParty / IrcLog2008-04-12

09:01:26 * stevenknight ( 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> Hi 09:02:09 <stevenknight> CoryCohen: hi 09:02:09 <Greg_Noel> Hello, you here for the bug party? 09:02:18 <CoryCohen> Yeah, just to lurk really. 09:02:25 <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> 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> 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> 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> 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> How much more is there to it then: linkscan = Scanner(function=mylinkscan, skeys=['.o']) 09:06:38 <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> 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> 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> Yes. 09:09:34 <stevenknight> but they'd be different if you were doing something else with the .o file 09:09:47 <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> Ok. 09:12:06 <stevenknight> in Tool/<ins>init</ins>.py, there are create{Prog,StaticLib,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> 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() 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> It is two rather small sentences. 09:25:14 <stevenknight> 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()... :-) 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 (n=jim@ has joined #scons 09:46:22 <Greg_Noel> 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> 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 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> 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> 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> 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> 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> I'm a monochrome kind of guy myself 10:00:16 <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> 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> 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:08:43 <stevenknight> $CPPSUFFIXES, $DSUFFIXES, $IDLSUFFIXES, $LATEXSUFFIXES, $LIBSUFFIXES, $FORTRANSUFFIXES... 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> 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> 648 not too hard to do, and would be handy 10:21:48 <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> Aye, that windows? 10:23:15 * bdbaddog2007 ( 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> 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: are you under Cygwin? 10:24:36 <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> 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> 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> 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> 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> 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> Ok. 10:26:54 <JimRandall> the /dev/null 10:27:08 <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 ( 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> Aye - it bit me 10:54:28 <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> seems to be because boost/algorithm (a directory) 10:54:59 <JimRandall> has a file that refers to the C++ STL file algorithm 10:55:17 <JimRandall> So possibly a saved result in a .sconsign causing trouble 10:55:23 <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() 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> 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: thanks for checking in 11:15:10 <CoryCohen> It's been educational for me. :-) 11:15:33 <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@ 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 ( 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 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> 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> 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> 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> Where I'd use it is in helping to track down cache corruption 11:34:47 <Greg_Noel> Happen often? 11:34:59 <JimRandall> Once every couple of months or so 11:35:09 <JimRandall> Sometimes once a month when things get busy 11:35:12 <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> 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@ 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> 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> 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> 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> 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> 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> 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 ( 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> caused by subst playing fast and loose with spaces I think 11:51:53 <JimRandall> can "fix" is by not using subst to expand the env variable 11:52:03 <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> 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> 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> 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> 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> Aye 12:06:00 <Greg_Noel> 1.x? 12:06:48 <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> 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> aye 12:08:54 <Azverkan> yep 12:09:06 <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> Azverkan == Brandon? 12:10:12 <Azverkan> yea 12:10:19 <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> 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> kinda sounds like it 12:23:08 <Greg_Noel> I'll take it and be sure. 12:23:59 <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> 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> 1937 dup and fixed 12:26:10 <Greg_Noel> ok, next 12:26:29 <JimRandall> 1940 future p3 consensus, and seems reasonable to me 12:26:55 <Greg_Noel> ok, next? 12:27:24 <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> sounds good to me 12:30:16 <Azverkan> yeah 12:30:26 <Greg_Noel> 1945? 12:30:29 <JimRandall> 1945 - part of the problem is being caused by a different bug 12:30:55 <Greg_Noel> which? 12:31:32 <JimRandall> hrm, one sec - not sure If I'm right about that 12:32:18 <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> ken 12:33:48 <Azverkan> sounds like exists vs lexists mismatch? 12:34:32 <Greg_Noel> Are you on 1945? 12:34:38 <JimRandall> I thought so 12:34:52 <JimRandall> Seemed odd to be complaining about an implicit dependency at all 12:35:03 <Azverkan> err no 12:35:29 <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> 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> 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> 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> Sure thing 12:40:49 <Greg_Noel> done 12:41:01 <Greg_Noel> 1946, lexists? 12:42:39 <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> 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> Sorry guys - I'm going to have to take off 12:56:29 <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> have fun all 12:57:10 <Greg_Noel> ok, cul. 12:57:16 <Azverkan> later