-
-
Notifications
You must be signed in to change notification settings - Fork 315
IrcLog2008 04 12
William Deegan edited this page Jan 14, 2016
·
2 revisions
09:01:26 * stevenknight (n=[stevenkn@c-69-181-234-155.hsd1.ca.comcast.net](mailto:stevenkn@c-69-181-234-155.hsd1.ca.comcast.net)) 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@66.119.167.101](mailto:jim@66.119.167.101)) 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: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](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=[Tiger@adsl-71-142-98-36.dsl.pltn13.pacbell.net](mailto:Tiger@adsl-71-142-98-36.dsl.pltn13.pacbell.net)) 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=[ita@57.Red-83-60-116.dynamicIP.rima-tde.net](mailto:ita@57.Red-83-60-116.dynamicIP.rima-tde.net)) 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 libtcl8.4.so, 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/Prog.py, 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@38.119.251.180](mailto:chatzill@38.119.251.180)) 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=[stevenkn@c-69-181-234-155.hsd1.ca.comcast.net](mailto:stevenkn@c-69-181-234-155.hsd1.ca.comcast.net)) 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, [http://scons.org/wiki/ReleaseTypes](http://scons.org/wiki/ReleaseTypes)
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@216.111.90.27](mailto:mikamike@216.111.90.27)) 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=[Gedeon@c-76-21-119-149.hsd1.ca.comcast.net](mailto:Gedeon@c-76-21-119-149.hsd1.ca.comcast.net)) 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