1 09:01:26 *	stevenknight (n=stevenkn@c-69-181-234-155.hsd1.ca.comcast.net) has joined #scons
   2 09:01:41 <stevenknight>	good morning...
   3 09:01:43 <Greg_Noel>	stevenknight, hello
   4 09:01:55 <Greg_Noel>	Nobody else here, yet?
   5 09:01:59 <CoryCohen>	Hi
   6 09:02:09 <stevenknight>	CoryCohen:  hi
   7 09:02:09 <Greg_Noel>	Hello, you here for the bug party?
   8 09:02:18 <CoryCohen>	Yeah, just to lurk really.
   9 09:02:25 <CoryCohen>	Did you see me email to the dev list?
  10 09:02:48 <Greg_Noel>	probably; what was the subject?
  11 09:02:59 <stevenknight>	yeah, the object file scanner for link dependencies?
  12 09:03:03 <CoryCohen>	Automatic link dependency generation using nm.
  13 09:03:23 <Greg_Noel>	Yeah, that's on my queue to answer after the bug party.
  14 09:03:33 <CoryCohen>	Ok.  I'll be patient then. :-)
  15 09:03:46 <Greg_Noel>	You probably have the scanner attached at the wrong place.
  16 09:03:52 <stevenknight>	my initial reaction:  +1
  17 09:03:53 <CoryCohen>	You guys have got plenty to do today it looks like.
  18 09:04:16 <Greg_Noel>	But no quorum yet
  19 09:04:29 <stevenknight>	i think you're just not setting up the scanner quite right
  20 09:04:41 <stevenknight>	scanning generated files works just fine for things like generated .h files
  21 09:04:52 <stevenknight>	but it can be a little non-obvious how to do it
  22 09:04:56 <CoryCohen>	That's likely.  I just started using SCons.
  23 09:05:07 <stevenknight>	in principle scanning objects should be like scanning generated .h files
  24 09:06:27 <CoryCohen>	How much more is there to it then: linkscan = Scanner(function=mylinkscan, skeys=['.o'])
  25 09:06:38 <CoryCohen>	env.Append(SCANNERS=linkscan)
  26 09:08:20 <stevenknight>	you also have to hook it up to the specific Builder involved
  27 09:08:38 <stevenknight>	scanning for dependencies is not purely a function of the source file type (i.e., the .o suffix)
  28 09:08:54 <CoryCohen>	Oh... The example had a Command builder, but I didn't think that was relevant.
  29 09:08:54 <stevenknight>	it's always done within the context of a specific target file that's being generated
  30 09:09:14 <CoryCohen>	Is there some magic I use to get the default object builder?
  31 09:09:18 <stevenknight>	the dependencies that you generate from a .o file are appropriate for linking into an executable
  32 09:09:26 <CoryCohen>	Yes.
  33 09:09:34 <stevenknight>	but they'd be different if you were doing something else with the .o file
  34 09:09:47 <CoryCohen>	(nods)
  35 09:09:53 <stevenknight>	yeah, "magic" is right...
  36 09:10:12 <stevenknight>	it's not something that's as easily configurable as it should be
  37 09:10:48 <stevenknight>	hang on a sec... looking...
  38 09:10:53 <CoryCohen>	Ok.
  39 09:12:06 <stevenknight>	in Tool/__init__.py, there are create{Prog,StaticLib,SharedLib,Object}Builder() functions
  40 09:12:23 <stevenknight>	that create the default builders for those types of things
  41 09:12:38 <stevenknight>	you can grep in Tool/*.py for examples of different tool modules that use them to add additional things
  42 09:12:56 <CoryCohen>	Great.  Thanks.
  43 09:13:01 <stevenknight>	suffixes, emitters, etc.
  44 09:13:20 <stevenknight>	there may be some additional surgery required, but keep asking when you get blocked
  45 09:13:36 <stevenknight>	Greg:  looks like it might be me and you again
  46 09:13:45 <Greg_Noel>	Yeah
  47 09:13:49 <stevenknight>	shall we get started?
  48 09:14:00 <Greg_Noel>	I only have one new point after last time
  49 09:14:17 <stevenknight>	?new point
  50 09:14:44 <Greg_Noel>	I was going over the issues and I noticed that 1872 was submitted by David
  51 09:15:24 <Greg_Noel>	I hadn't noticed that the first time
  52 09:15:41 <Greg_Noel>	With that the case, I propose to give it to him
  53 09:15:53 <stevenknight>	+1
  54 09:16:19 <Greg_Noel>	Then as far as I know, there's nothing that we didn't discuss last time
  55 09:16:29 <stevenknight>	i was scanning editlist2008 before and had one change of heart
  56 09:16:38 <Greg_Noel>	Which?
  57 09:16:48 <stevenknight>	Bill's argument that we add the BuildDir() deprecation warning for 1.0 makes sense to me
  58 09:17:09 <stevenknight>	that's #1906
  59 09:17:22 <Greg_Noel>	I think it's too soon
  60 09:17:42 <stevenknight>	for just a warning?
  61 09:18:12 <Greg_Noel>	Well, I don't use it, so I won't fight it, but ...
  62 09:18:31 <Greg_Noel>	... those that do could be annoyed.
  63 09:18:57 <stevenknight>	true
  64 09:19:23 <stevenknight>	but they'll be annoyed when it happens in 1.x, too
  65 09:19:25 <Greg_Noel>	Given that it's so misunderstood, how many users do you think it has?
  66 09:19:40 <stevenknight>	excellent question
  67 09:19:57 <HM2>	Can anyone tell me how I can get scons to activate SConstruct files in subdirectories?
  68 09:20:01 <stevenknight>	probably fairly common
  69 09:20:13 <Greg_Noel>	Then they need time to switch.
  70 09:20:16 <stevenknight>	HM2:  hang on a sec while we finish this thread
  71 09:20:30 <HM2>	k..
  72 09:21:11 <stevenknight>	how much time?
  73 09:21:20 <Greg_Noel>	There have been deprecation warnings for Copy() ==> Clone() for a year
  74 09:21:45 <Greg_Noel>	I don't think it really needs more than a few months, but 1.1 sounds reasonable.
  75 09:22:52 <Greg_Noel>	(See, I think there will be a 1.1.)
  76 09:23:09 <stevenknight>	guess I can live with that, provided our "THIS WILL CHANGE" warnings in the doc are prominent enough
  77 09:23:10 <stevenknight>	are they?
  78 09:23:19 <stevenknight>	agree re: there being a likely 1.1
  79 09:23:46 <Greg_Noel>	I think you need the BIG CAPS, but yes; I certainly see them.
  80 09:24:06 <Greg_Noel>	... but then, I'm a reader, I actually _see_ what's in the print.
  81 09:24:30 <stevenknight>	that definitely differentiates you from the great mass of us who mostly just skim...  :-)
  82 09:24:34 <CoryCohen>	It is two rather small sentences.
  83 09:25:14 <stevenknight>	CoryCohen:  good point
  84 09:25:43 <stevenknight>	so let's leave 1906 for 1.x
  85 09:25:59 <stevenknight>	but add another item for 0.98.1 to enhance the warnings in the doc:
  86 09:26:08 <Greg_Noel>	I actually like the schedule that's in the wiki...
  87 09:26:13 <stevenknight>	indented "IMPORTANT NOTE:" block quotes or something
  88 09:26:26 <Greg_Noel>	... one release with a doc warning
  89 09:26:47 <Greg_Noel>	... one release with a compile warning that can be turned off
  90 09:26:54 <Greg_Noel>	... one release with a compile warning that can't be turned off
  91 09:27:14 <Greg_Noel>	... one release with a fatal error
  92 09:27:48 <Greg_Noel>	The block quote for emphasis sounds reasonable
  93 09:28:01 <stevenknight>	where "one release" is a major (x.y) release, not something like 0.98.1, yes?
  94 09:28:18 <Greg_Noel>	That's minor release, but yes
  95 09:28:32 <stevenknight>	okay
  96 09:28:58 <stevenknight>	so i'll open a 0.98.1 issue to add block quotes
  97 09:29:06 <stevenknight>	and 1906 is 1.x
  98 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
  99 09:30:13 <stevenknight>	so minimum case that's about a year of lead time
 100 09:30:15 <stevenknight>	should be reasonable
 101 09:32:02 <stevenknight>	HM2:  SConstruct files in subdirectories
 102 09:32:08 <stevenknight>	there's nothing magic about the file name 'SConscript'
 103 09:32:21 <stevenknight>	you should be able to just put
 104 09:32:28 <stevenknight>	SConscript("subdir/SConstruct")
 105 09:32:36 <HM2>	...right
 106 09:32:39 <stevenknight>	in any file and it will read up the subsidiary
 107 09:32:47 <HM2>	well atm i'm still trying to get a seperate builddir
 108 09:33:44 <stevenknight>	the tricky part with subsidiary SConstruct files is the .sconsign files that store the build information
 109 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?
 110 09:34:28 <HM2>	is SConstruct == SConscript?
 111 09:34:58 <stevenknight>	all SCons config files are just Python scripts that get executed to set up the dependencies and stuff
 112 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
 113 09:35:16 <stevenknight>	the only magic name is SConstruct, which we use as the top level of the build
 114 09:35:26 <stevenknight>	everything else is just convention
 115 09:35:41 <stevenknight>	you include them in the build by calling SConscript(), but they can be named anything
 116 09:36:08 <HM2>	;(
 117 09:37:08 <Greg_Noel>	HM2, builddir doesn't do dual mimicry
 118 09:37:40 <stevenknight>	actually it does (or is supposed to); what would the mimicked include/some/random/path be used for?
 119 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
 120 09:38:30 <Greg_Noel>	To construct the install tree; we've been at this point before
 121 09:38:38 <HM2>	hmm
 122 09:38:54 <HM2>	this is odd
 123 09:39:11 <stevenknight>	???  oh, discusing this before I showed up?
 124 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.
 125 09:39:27 <HM2>	i use env = Environment (CPPPATH = 'include' in my "src" dir and it builds fine...include is ../include relative to "src"
 126 09:39:50 <HM2>	but with a build dir it expects to find build/include
 127 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
 128 09:41:04 <stevenknight>	okay, I thought this might have been a quick question to handle
 129 09:41:11 <stevenknight>	but it sounds like we need to go into more depth
 130 09:41:19 <stevenknight>	didn't mean to derail the bug dicussion to this extent
 131 09:41:21 <HM2>	scons doesn't correct include paths when it uses a build dir?
 132 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.
 133 09:42:00 <stevenknight>	Greg's exactly right
 134 09:42:06 <HM2>	ah it builds!
 135 09:42:22 <HM2>	at last some sanity
 136 09:42:30 <Greg_Noel>	no quorum, why not?
 137 09:42:50 <stevenknight>	hmm, that might be the first time I've heard "sanity" used in a discussion of BuildDir()...  :-)
 138 09:42:57 <Greg_Noel>	concur!
 139 09:43:12 <HM2>	and it didn't copy my source files!
 140 09:43:13 <HM2>	wowza
 141 09:43:24 <stevenknight>	HM2:  you're using duplicate=0?
 142 09:43:28 <HM2>	yes
 143 09:43:34 <stevenknight>	yeah, that's the way it should work, then
 144 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
 145 09:44:10 <HM2>	possibly?
 146 09:44:13 <stevenknight>	ah, batch builders...!
 147 09:44:14 <HM2>	with Object()?
 148 09:44:20 <Greg_Noel>	can't, see issue 1086
 149 09:44:26 <stevenknight>	yes
 150 09:44:42 <stevenknight>	you'd have to basically do your own custom Builder or Command right now
 151 09:45:18 <stevenknight>	we're discussing how to extend our model to support it more naturally
 152 09:45:34 <HM2>	I see
 153 09:45:50 <HM2>	doesn't python support nested lists? seems the obvious way to do it
 154 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
 155 09:46:06 <Greg_Noel>	ah, er, um, Java
 156 09:46:08 *	JimRandall (n=jim@66.119.167.101) has joined #scons
 157 09:46:22 <Greg_Noel>	JimRandall, you're late....
 158 09:46:24 <stevenknight>	the trick is that SCons won't (by default) realize that multiple .o files get created from it
 159 09:46:51 <JimRandall>	Indeed - better late than never :)
 160 09:47:00 <stevenknight>	but Jim's here!  better than some others...
 161 09:47:05 <stevenknight>	yes
 162 09:47:17 <Greg_Noel>	No quorum, so we've been chatting...
 163 09:47:36 <HM2>	stevenknight : no i mean multiple .c files into one .o file
 164 09:47:44 <Greg_Noel>	Does three constitute a quorum?
 165 09:47:57 <stevenknight>	most substantive decision so far has been to *not* enable deprecation warnings for BuildDir until 1.x
 166 09:48:15 <stevenknight>	but for 0.98.1 enhance the warnings in the doc with caps or block quotes
 167 09:48:27 <JimRandall>	And maybe a few large arrows
 168 09:48:28 <stevenknight>	I'd say three is sufficient
 169 09:48:28 <Greg_Noel>	(both)
 170 09:48:54 <JimRandall>	Thought I don't use it, so I'd not notice it anyway :)
 171 09:48:59 <stevenknight>	if we keep postponing things waiting for enough people to participate, it'll never happen
 172 09:49:18 <Greg_Noel>	true, shall we start?
 173 09:49:32 <stevenknight>	yes, let's create the momentum and let others catch up to the train
 174 09:49:50 <stevenknight>	once they realize we're making all sorts of decisions they disagree with...  :-)
 175 09:50:10 <Greg_Noel>	ok, 449? (shudder)
 176 09:50:37 <stevenknight>	HM2:  your best bet right now for multiple .c files into one .o file is to do a custom Command()
 177 09:50:44 <stevenknight>	yes, 449:
 178 09:51:08 <Greg_Noel>	I have to admit I don't understand it
 179 09:51:16 <Greg_Noel>	Gary was carrying this ball
 180 09:51:41 <stevenknight>	449:  future, p3, put gary's name on it
 181 09:51:45 <Greg_Noel>	done
 182 09:51:53 <stevenknight>	if it languishes it's because there isn't enough demand anyway
 183 09:52:03 <Greg_Noel>	468?
 184 09:52:03 <JimRandall>	aye - doesn't seem that critical
 185 09:52:22 <stevenknight>	468:  how about turning this into a doc issue?
 186 09:52:33 <Greg_Noel>	hmmm... possible
 187 09:52:34 <stevenknight>	just show people how to use atexit for this pattern?
 188 09:52:45 <Greg_Noel>	yes, I like it.  done
 189 09:52:50 <JimRandall>	Aye
 190 09:52:51 <Greg_Noel>	when?
 191 09:53:05 <stevenknight>	1.0
 192 09:53:13 <stevenknight>	with all the other User's Guide things
 193 09:53:24 <Greg_Noel>	ok, I'll make it yours.
 194 09:53:28 <stevenknight>	anything that we can't actually finish by then will get promoted en masse to 1.
 195 09:53:29 <stevenknight>	1.x
 196 09:53:33 <stevenknight>	yes, mine
 197 09:54:05 <Greg_Noel>	505, future.  _far_ future.
 198 09:54:13 <stevenknight>	skip 484?
 199 09:54:31 <Greg_Noel>	oops
 200 09:54:42 <stevenknight>	484:  1.x, but I'm not sure who
 201 09:55:09 <stevenknight>	might as well be me if there's no one else obvious
 202 09:55:14 <Greg_Noel>	I'd do it, but I've never hacked that area
 203 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... :-/
 204 09:55:51 <Greg_Noel>	I can certainly add a note to explain the problem more clearly; that might make it easier.
 205 09:56:01 <HM2>	scons -c doesn't kill empty directories in the build directory then?
 206 09:56:06 <HM2>	even though it creates them
 207 09:56:24 <Greg_Noel>	HM2, nope, not as a rule.  unfortunately.
 208 09:56:25 <stevenknight>	HM2:  correct, no one's come up with code to do it
 209 09:57:01 <Greg_Noel>	does that work for 484?
 210 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
 211 09:57:05 <HM2>	odly i'm now getting /build/build/geometry 
 212 09:57:25 <Greg_Noel>	Take the 'builddir' out of your subdirs.
 213 09:57:33 <HM2>	i see
 214 09:57:43 <stevenknight>	484:  1.x, P3, assign to me, add the note you were talking about
 215 09:57:48 <Greg_Noel>	done
 216 09:57:58 <Greg_Noel>	next 505>
 217 09:58:06 <stevenknight>	505:  i don't think it's that far off
 218 09:58:42 <stevenknight>	and, honestly, it bugs me that waf makes a big deal of having it
 219 09:58:47 <Greg_Noel>	I just see no reason for it, but then, I've used stone-age tools since the stone age
 220 09:58:56 <HM2>	aweosme
 221 09:59:00 <HM2>	this is working well
 222 09:59:14 <stevenknight>	HM2:  cool, glad to hear it
 223 09:59:26 <stevenknight>	HM2:  a little tricky to get set up, but it's slick once everything's in place
 224 09:59:44 *	HM2 now has to play with install() ?
 225 09:59:47 <Greg_Noel>	Jim, an opinion?  I'll not stand in the way.
 226 09:59:54 <stevenknight>	the build log part of 505 becomes really necessary for continuous integration systems
 227 09:59:59 <JimRandall>	I'm a monochrome kind of guy myself
 228 10:00:16 <JimRandall>	Though I seem to be in the minority there too :)
 229 10:00:18 <stevenknight>	how about splitting 505?
 230 10:00:44 <Greg_Noel>	how?
 231 10:01:00 <stevenknight>	i can see the color being a nice-to-have, but logging is downright useful
 232 10:01:21 <stevenknight>	i guess I don't want to see the latter get pushed out because we're iffy about colorizing output
 233 10:01:28 <JimRandall>	Agreed - logging was one of the very first things I bolted on top of scons
 234 10:01:51 <stevenknight>	how about give it me and mark it research?
 235 10:01:56 <Greg_Noel>	Being a UNIX guy, I just use tee.
 236 10:02:12 <stevenknight>	can't just use tee in a continuous integration system like Buildbot or Pulse
 237 10:02:14 <Greg_Noel>	ok, done, research, steven
 238 10:02:32 <Greg_Noel>	Er, I do, works fine.
 239 10:02:53 <stevenknight>	???
 240 10:03:09 <stevenknight>	oh, i get it
 241 10:03:16 <Greg_Noel>	trust me, more than one way to skin a cat
 242 10:03:35 <stevenknight>	sorry, i'm thinking of using it in conjunction with -j
 243 10:03:47 <stevenknight>	intermixed error messages
 244 10:03:59 <Greg_Noel>	different problem
 245 10:03:59 <JimRandall>	Now that would be an interesting use of colourization too
 246 10:04:09 <stevenknight>	yeah, you're right, i'm getting them mixed up
 247 10:04:29 <stevenknight>	i was thinking of it as a -j issue because the only time i use it is in buidlbot
 248 10:04:48 <stevenknight>	sorry, i've taken us down a rathole again...
 249 10:04:53 <stevenknight>	513?
 250 10:05:24 <Greg_Noel>	I think the whole issue of suffixes needs work, but it may not be this issue.
 251 10:05:55 <stevenknight>	agreed
 252 10:06:05 <stevenknight>	i've taken a run at this once or twice but never got far enough
 253 10:07:02 <Greg_Noel>	I suspect this one needs to be closed and a new issue opened that's more focused.
 254 10:07:12 <stevenknight>	it's really dumb, though, that other suffixes can be configure and this one can't
 255 10:07:46 <Greg_Noel>	(they can?)
 256 10:07:59 <stevenknight>	i believe so...
 257 10:08:11 <Greg_Noel>	hmmm...
 258 10:08:11 <stevenknight>	we do support the following variables:
 259 10:08:43 <stevenknight>	$CPPSUFFIXES, $DSUFFIXES, $IDLSUFFIXES, $LATEXSUFFIXES, $LIBSUFFIXES, $FORTRANSUFFIXES...
 260 10:09:20 <HM2>	I presume to pass environment junk to SConscript()'d files I need to export or something?
 261 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
 262 10:09:33 <HM2>	to the environment
 263 10:09:57 <stevenknight>	HM2:  yes, check out the Export() function or the export= argument to SConscript()
 264 10:10:09 <stevenknight>	HM2:  and Import() on the SConscript side
 265 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.
 266 10:11:31 <stevenknight>	back to 513:  give it to me, 2.x, p2
 267 10:11:38 <Greg_Noel>	It's that part that I think needs significant speedup.
 268 10:11:45 <Greg_Noel>	ok, done; next?
 269 10:11:48 <stevenknight>	agreed re: speedup
 270 10:11:57 <stevenknight>	it shouldn't require a new tool, just making the existing one smarter
 271 10:12:21 <Greg_Noel>	And maybe some way to configure it _without_ loading all the Tools.
 272 10:12:36 <stevenknight>	555:  this is less crucial with Anatoly's scons.bat fix
 273 10:12:43 <HM2>	I am very very impressed
 274 10:12:46 <stevenknight>	(agree re: configuration without loading more tools)
 275 10:13:06 <Greg_Noel>	555, not of interest to a UNIX guy ;-}
 276 10:13:11 <stevenknight>	:-)
 277 10:13:26 <HM2>	no annoying MACRO_LANGUAGE_GARBAGE, Scons seems clean
 278 10:13:39 <stevenknight>	now that we scons.bat is smarter, 555 should just be part of overall Windows installation fixing
 279 10:13:48 <Greg_Noel>	pick your poison on it; I'll go along
 280 10:13:49 <JimRandall>	sounds good
 281 10:14:03 <stevenknight>	let's just close this one, the Windows installation is recorded elsewhere
 282 10:14:19 <stevenknight>	FIXED by the scons.bat change, dup it to the one I just integrated
 283 10:14:27 <stevenknight>	let me get a number for you...
 284 10:15:18 <stevenknight>	555 is dup 1882
 285 10:15:40 <stevenknight>	561:
 286 10:15:44 <Greg_Noel>	typing ahead, 561 said CVS('subdir/file')
 287 10:16:13 <Greg_Noel>	rather than 'CVS(.)' n the subdir
 288 10:16:25 <Greg_Noel>	oops, modulo quoting
 289 10:16:26 <stevenknight>	ah!  okay, i get it
 290 10:16:28 <stevenknight>	INVALID
 291 10:16:31 <Greg_Noel>	done
 292 10:16:52 <stevenknight>	633:  windows installation
 293 10:16:53 <Greg_Noel>	skip 646
 294 10:17:19 <Greg_Noel>	oops, I'm off again.
 295 10:17:51 <Greg_Noel>	yes, defer until we know about GSoC project
 296 10:17:58 <stevenknight>	agreed
 297 10:18:49 <Greg_Noel>	646
 298 10:19:04 <Greg_Noel>	(been so long I've forgotten this)
 299 10:19:34 <stevenknight>	646:  2.x, me, p3
 300 10:19:57 <stevenknight>	we're just not consistent about how we do this searching-for-tools thing
 301 10:20:25 <Greg_Noel>	I'll add a note to it; should be possible with Dir('bin')
 302 10:20:47 <Greg_Noel>	648
 303 10:20:48 <stevenknight>	okay, cool
 304 10:21:23 <stevenknight>	648:  I agree with you:  1.x, p4
 305 10:21:23 <Greg_Noel>	DOS, ick.
 306 10:21:33 <JimRandall>	648 not too hard to do, and would be handy
 307 10:21:48 <JimRandall>	Can send that one to me.
 308 10:21:54 <stevenknight>	Jim, you interested?  If not, I might be able to look at it as part of..
 309 10:21:54 <Greg_Noel>	done, both
 310 10:21:55 <stevenknight>	okay...
 311 10:22:06 <stevenknight>	659:
 312 10:22:50 <stevenknight>	more windows command line, Jim you okay with taking this one too?
 313 10:23:09 <JimRandall>	Aye, that windows?
 314 10:23:15 *	bdbaddog2007 (n=Tiger@adsl-71-142-98-36.dsl.pltn13.pacbell.net) has joined #scons
 315 10:23:27 <stevenknight>	Bill!
 316 10:23:33 <Greg_Noel>	Stylishly late?
 317 10:23:43 <stevenknight>	we gave you lots and lots and LOTS of action items... :-)
 318 10:23:53 <CoryCohen>	Sorry, bit late here... 659 works just fine for me.
 319 10:23:57 <bdbaddog2007>	G'morning.. Yes weekend mornings are difficult for me.
 320 10:24:32 <stevenknight>	CoryCohen:  are you under Cygwin?
 321 10:24:36 <CoryCohen>	Windows, cygwin, cut-and-pasted the test case.
 322 10:24:37 <Greg_Noel>	So it's fixed now, by something other that us?
 323 10:24:44 <stevenknight>	no, i don't think it's fixed
 324 10:25:02 <CoryCohen>	The shell should not care about the space (or lack thereof).
 325 10:25:05 <stevenknight>	under cygwin you're using their UNIX-shell derivative
 326 10:25:14 <CoryCohen>	I'm deeply suspicious of a not-real bash shell.
 327 10:25:17 <stevenknight>	i think this is about using Windows' cmd.exe
 328 10:25:43 <CoryCohen>	Yeah.  That's mote likely, but the reporter appears to have ls, etc.
 329 10:26:09 <stevenknight>	ah, true
 330 10:26:15 <stevenknight>	maybe it *is* fixed then...
 331 10:26:25 <CoryCohen>	Not that I'm against fixing it, but I think it's the shell that broken.
 332 10:26:25 <stevenknight>	hang, on, let me boot up my Windows laptop
 333 10:26:34 <JimRandall>	Agreed - it doesn't run under plain vanilla windows
 334 10:26:34 <stevenknight>	i'll test it on a non-Cygwin system while we move on
 335 10:26:51 <CoryCohen>	Ok.
 336 10:26:54 <JimRandall>	the /dev/null
 337 10:27:08 <JimRandall>	It can't find that file for some reason :)
 338 10:28:08 <Greg_Noel>	695: I'm not sure get_contents is the right API to expose
 339 10:28:21 <stevenknight>	662:  dup 1882
 340 10:28:42 <stevenknight>	695:  agree w/Greg
 341 10:28:49 <Greg_Noel>	662: done
 342 10:29:35 <stevenknight>	695:  I'd prefer to expose something called read() so it looks like a Python file handle
 343 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 ?
 344 10:30:05 <stevenknight>	sounds good
 345 10:30:07 <bdbaddog2007>	695 that is, and close it ?
 346 10:30:28 <Greg_Noel>	ok, done (but note that Value already has read)
 347 10:31:04 <Greg_Noel>	720
 348 10:31:57 <Greg_Noel>	Ah, I think you're right about Rob; Mark Flacy for Java.
 349 10:32:52 <stevenknight>	659:  it works even under vanilla Windoze
 350 10:32:55 <stevenknight>	FIXED
 351 10:33:04 <stevenknight>	720:  agree re: Rob
 352 10:33:16 <stevenknight>	and Mark (if he's interested)
 353 10:33:45 <stevenknight>	Greg, would you either approach them yourself, or be a burr under my saddle for me to do it?
 354 10:33:52 <Greg_Noel>	I'll write them.
 355 10:33:55 <stevenknight>	I suck at staying on-task with that sort of things...
 356 10:34:11 <Greg_Noel>	Me, too, but I have a nag list...
 357 10:34:28 <stevenknight>	okay, on to 2008?
 358 10:34:34 <Greg_Noel>	I'll also ask Rob if he thinks it's fixed.
 359 10:34:39 <Greg_Noel>	yes, 2008
 360 10:34:40 <stevenknight>	cool
 361 10:35:06 <Greg_Noel>	1872
 362 10:35:16 <stevenknight>	1872:  consensus 2.x, p2
 363 10:35:27 <Greg_Noel>	I noticed this was from David, so I recanted.
 364 10:36:02 <stevenknight>	meaning you're okay with that consensus?
 365 10:36:28 <Greg_Noel>	No, I originally suggested 2.x; I recanted and now suggest 1.x.
 366 10:36:44 <stevenknight>	oh, I see
 367 10:36:57 <Greg_Noel>	I'm still ok with 2.x, but if we're giving David things to do...
 368 10:37:34 <Greg_Noel>	Why not 2.x and ask him if he thinks it can be 1.x?
 369 10:37:41 <stevenknight>	sure, if he's up for it.  1.x.  worst that happens is we end up pushing it out
 370 10:37:46 <stevenknight>	i'd say go the other way
 371 10:37:52 <Greg_Noel>	ok, done.
 372 10:37:58 <stevenknight>	make sure we at least consider it for 1.x and push out if need be
 373 10:38:10 <stevenknight>	instead of having things on the 2.x list that we don't consider pulling in
 374 10:38:46 <Greg_Noel>	1873
 375 10:38:56 <stevenknight>	1873:  1.x, p2
 376 10:39:07 <Greg_Noel>	Ouch.  You sure?
 377 10:39:23 <stevenknight>	i think trying to do something more friendly with this stuff sooner rather than later is important
 378 10:39:29 <Greg_Noel>	ok, done.
 379 10:39:43 <stevenknight>	not sure if it wil actually make it by then, but we should try
 380 10:40:03 <Greg_Noel>	1874
 381 10:40:07 <bdbaddog2007>	:)
 382 10:40:17 <bdbaddog2007>	I'm not sure my bug report on this one captured the issue.
 383 10:40:26 *	ita (n=ita@57.Red-83-60-116.dynamicIP.rima-tde.net) has joined #scons
 384 10:40:48 <Greg_Noel>	yes, it did.  I just don't see any general solution.
 385 10:40:55 <stevenknight>	right
 386 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.
 387 10:41:15 <Greg_Noel>	How can you tell when the dot is a suffix or part of the name.
 388 10:41:20 <stevenknight>	always adding the suffix is wrong for some configurations.  not adding the suffix is wrong for some configurations
 389 10:41:40 <bdbaddog2007>	this is specifically for shared library names.
 390 10:42:13 <Greg_Noel>	Well, is it the same for .dylib?  .pylib?  .dll?
 391 10:42:30 <Greg_Noel>	Too many variations.
 392 10:42:48 <bdbaddog2007>	this is for shared libraries found by findlib
 393 10:43:16 <bdbaddog2007>	where it trys a number of name variations.
 394 10:43:30 <bdbaddog2007>	with and without suffix, but in this case doesn't try suffix.
 395 10:44:20 <Greg_Noel>	Does the workaround work?
 396 10:45:11 <stevenknight>	oh, okay, so this is in Scanner/Prog.py, yes?
 397 10:45:31 <bdbaddog2007>	hold on lemme bring up the file.
 398 10:45:51 <bdbaddog2007>	actually if you want we can defer this bug til later.
 399 10:46:09 <stevenknight>	yeah, i found it
 400 10:46:11 <Greg_Noel>	yes, table, discuss in mailing list.
 401 10:46:26 <stevenknight>	it's a real bug
 402 10:46:41 <stevenknight>	table and discuss
 403 10:46:53 <Greg_Noel>	1897, dup, three agreed
 404 10:47:12 <stevenknight>	you mean 1879, yes?
 405 10:47:14 <bdbaddog2007>	1879 right?
 406 10:47:32 <Greg_Noel>	sigh, dyslexia...
 407 10:47:53 <stevenknight>	dyslexics of the world untie!
 408 10:48:14 <stevenknight>	(I get to say that because both my wife and daughter are...)
 409 10:48:31 <Greg_Noel>	makes sense to me...
 410 10:48:36 <stevenknight>	1880:
 411 10:49:00 <stevenknight>	1880:  2.x, drop it even to p4?
 412 10:49:02 <Greg_Noel>	Didn't Gary also report a 1880-ish issue?
 413 10:49:22 <stevenknight>	this is the sort of thing Benoit is really good at tracking down
 414 10:49:38 <Greg_Noel>	good idea, I'll ask him.  Next?
 415 10:50:00 <stevenknight>	1883:  much less an issue with the scons.bat patch
 416 10:50:35 <stevenknight>	i'd like to put it under the general windows installation umbrella
 417 10:50:43 <Greg_Noel>	works for me
 418 10:50:46 <stevenknight>	however we decide to actually record that...
 419 10:51:18 <bdbaddog2007>	wiki page? or a  bug which depends on other bugs ?
 420 10:51:24 <Greg_Noel>	Why don't I create a keyword?
 421 10:51:30 <bdbaddog2007>	I usually like the bug which depends on other bugs..
 422 10:51:49 <stevenknight>	i like both the keyword and the umbrella bug
 423 10:51:59 <bdbaddog2007>	even better..
 424 10:52:00 <bdbaddog2007>	:)
 425 10:52:01 <Greg_Noel>	ok, I'll work something up
 426 10:52:04 <Greg_Noel>	next?
 427 10:52:05 <stevenknight>	thanks
 428 10:52:35 <stevenknight>	1885:  see if Rob Managan will take it?
 429 10:52:39 <Greg_Noel>	I'll ask Rob
 430 10:52:44 <stevenknight>	done
 431 10:52:46 <Greg_Noel>	next
 432 10:53:37 <stevenknight>	1889:  consensus research
 433 10:53:41 <Greg_Noel>	we've been seeing a bunch of these lately; there was another on the mailing list day before yesterday.
 434 10:53:50 <bdbaddog2007>	yes saw that.
 435 10:53:58 <Greg_Noel>	research, who?
 436 10:54:15 <stevenknight>	Jim, you had some exposure to the problem...?
 437 10:54:19 <JimRandall>	Aye - it bit me
 438 10:54:28 <JimRandall>	Tried to create a reproducible case, but had a hard time
 439 10:54:35 <bdbaddog2007>	would this be related to the other bug dealing with caching and the contents of a directory changing?
 440 10:54:37 <JimRandall>	seems to be because boost/algorithm (a directory)
 441 10:54:59 <JimRandall>	has a file that refers to the C++ STL file algorithm
 442 10:55:17 <JimRandall>	So possibly a saved result in a .sconsign causing trouble
 443 10:55:23 <JimRandall>	or a scanner issue?
 444 10:55:28 <stevenknight>	hmm, that might be enough to go on
 445 10:55:30 <stevenknight>	probably scanner
 446 10:55:39 <stevenknight>	put my name on it, leave it research
 447 10:55:46 <Greg_Noel>	done, next?
 448 10:56:01 <stevenknight>	1891:  me, research, p3
 449 10:56:13 <stevenknight>	i'm taking a fresh look at the windows support in general
 450 10:56:21 <Greg_Noel>	ok, done, next?
 451 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.
 452 10:57:15 <Greg_Noel>	1894, future, three votes
 453 10:57:36 <stevenknight>	nano-:  calling env.Tool() on each tool in your list?
 454 10:57:51 <stevenknight>	1894:  done
 455 10:58:20 <Greg_Noel>	skip 1896
 456 10:58:22 <stevenknight>	1895:  i'd say research, gary (overall toolchain refactor)
 457 10:58:28 <nano->	stevenknight: Huh.. it does? I tried adding a print, but it was at least hidden.
 458 10:58:42 <nano->	stevenknight: Also, no matter what that method returns, the tool is still generated. 
 459 10:58:53 <stevenknight>	nano-:  not sure I understand your original question
 460 10:59:30 <stevenknight>	nano-:  oh, you mean just get the list of Tool modules *without* having them call generate()?
 461 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. 
 462 10:59:50 <nano->	Because tools are loaded even if their executables aren't found. 
 463 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. 
 464 11:00:55 <Greg_Noel>	1895, not sure it's toolchain.  Sounds like Detect()
 465 11:01:23 <stevenknight>	nano-:  no good public API for doing what you want
 466 11:01:58 <stevenknight>	nano-:  look in Tool/__init__.py for things that might get you close
 467 11:02:10 <nano->	So what's the reason for exists() in Tools anyway? As it doesn't seem to matter what it does.
 468 11:02:31 <stevenknight>	nano-:  specifically things like Findtool(), FindAllTools()
 469 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
 470 11:03:32 <Greg_Noel>	1895, put on Gary's plate to research?
 471 11:03:39 <stevenknight>	Greg_Noel:  1895, gary, research
 472 11:03:41 <nano->	Yeah, but env.Tool() will fail if the executables aren't found?
 473 11:03:47 <Greg_Noel>	done
 474 11:03:50 <nano->	Not that I've noticed. 
 475 11:04:17 <nano->	Oh, nevermind.. go on with your bug talks instead of this one. 
 476 11:04:25 <stevenknight>	1896:  skip, alrady integrated
 477 11:04:26 <Greg_Noel>	1900
 478 11:04:57 <Greg_Noel>	where is the intel() tool used?
 479 11:05:14 <ita>	stevenknight: is the great signature refactoring complete?
 480 11:06:25 <Greg_Noel>	Sigh.  Should we just stop?  We're getting more interruptions than work done.
 481 11:06:30 <stevenknight>	1900:  not sure, this strikes me as another gary research
 482 11:06:59 <stevenknight>	Greg_Noel:  yeah, we should stop -- i have to peel off soon anyway
 483 11:07:03 <stevenknight>	ita:  hey Thomas
 484 11:07:13 <Greg_Noel>	ok, I'll put it on his plate.
 485 11:07:14 <stevenknight>	yes, the signature refactoring was released in 0.98.0
 486 11:07:35 <stevenknight>	"complete" is a relative word...  :-)
 487 11:07:36 <Greg_Noel>	1901, done.
 488 11:07:49 <ita>	stevenknight: ok, thanks
 489 11:08:03 <stevenknight>	some side effects are still turning up, but they're in increasingly obscure corner cases
 490 11:09:22 <Greg_Noel>	1904, I think this just showed up in the wiki; what to do with it otherwise?
 491 11:10:37 <Greg_Noel>	future, what priority?
 492 11:11:03 <bdbaddog2007>	if he can get some test together could we pull it in? shouldn't impact anything else right?
 493 11:12:07 <Greg_Noel>	We lack a general framework for _any_ testing; without that, this will just change when we do.
 494 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?
 495 11:13:44 <stevenknight>	bdbaddog2007:  that could work
 496 11:14:08 <Greg_Noel>	fine with me; Bill, you want to chase it?
 497 11:14:20 <bdbaddog2007>	sure. 
 498 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.
 499 11:14:39 <Greg_Noel>	ok,I'll assign it to you.
 500 11:14:55 <stevenknight>	CoryCohen:  thanks for checking in
 501 11:15:10 <CoryCohen>	It's been educational for me. :-)
 502 11:15:33 <CoryCohen>	Bye!
 503 11:15:54 <Greg_Noel>	1905, don't know what to suggest.
 504 11:16:42 <bdbaddog2007>	Float a message on user and dev mailing lists sugguesting retiring this and see what feedback there is?
 505 11:17:04 <Greg_Noel>	Works.  Who should send it?  Steven?
 506 11:17:15 <stevenknight>	probably
 507 11:17:38 <Greg_Noel>	ok, you for research?
 508 11:17:42 *	Administrator (n=chatzill@38.119.251.180) has joined #scons
 509 11:17:42 <stevenknight>	yeah
 510 11:18:01 *	Administrator is now known as Azverkan
 511 11:19:04 <stevenknight>	1906:  greg and i were talking about it earlier
 512 11:19:15 <stevenknight>	our consensus was to save the deprecation warning until 1.x
 513 11:19:28 <stevenknight>	but make the will-be-deprecated documentation much more noticeable
 514 11:19:36 <stevenknight>	caps, bold, block quotes
 515 11:19:56 <stevenknight>	gotta go
 516 11:20:02 <Greg_Noel>	One more?
 517 11:20:06 <bdbaddog2007>	:( I still think 1.0 is the place to put it for reasons stated in spreadsheet.
 518 11:20:09 <stevenknight>	one last:   1907
 519 11:20:13 <Greg_Noel>	1907?
 520 11:20:23 <stevenknight>	i tried to integrate this morning
 521 11:20:35 <stevenknight>	it's conflicting with another of Benoit's patches
 522 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
 523 11:20:52 <Greg_Noel>	Get him to resolve them?
 524 11:20:56 <stevenknight>	yeah
 525 11:21:00 <Greg_Noel>	Should I write him?
 526 11:21:10 <stevenknight>	sure, if you could that would be helpful
 527 11:21:24 <Greg_Noel>	(Bill, talk to me later about 1906)
 528 11:21:31 <Greg_Noel>	ok, wilco.
 529 11:21:32 <stevenknight>	okay, thanks everyone -- i'm out
 530 11:21:35 <bdbaddog2007>	ok
 531 11:21:37 *	stevenknight (n=stevenkn@c-69-181-234-155.hsd1.ca.comcast.net) has left #scons ("Leaving")
 532 11:22:48 <Greg_Noel>	Bill, it's just too soon for a warning.  You've got to give people time to convert.
 533 11:23:25 <bdbaddog2007>	I thought that was the purpose of deprecation message
 534 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.
 535 11:23:48 <Greg_Noel>	A warning in the manual is appropriate.
 536 11:24:09 <Greg_Noel>	Look at, uh, http://scons.org/wiki/ReleaseTypes
 537 11:24:44 <bdbaddog2007>	Yeah I guess I can see that, but do we put warning in 2.0 release candidates then?
 538 11:25:17 <bdbaddog2007>	1.0.1 ?
 539 11:26:12 <Greg_Noel>	1.1 or 2.0 release candidates, whichever comes first.
 540 11:26:22 <bdbaddog2007>	o.k. I see your point.
 541 11:26:32 <bdbaddog2007>	so 1.x the deprecation then?
 542 11:26:41 <Greg_Noel>	yes
 543 11:27:32 <bdbaddog2007>	o.k. sounds good.
 544 11:27:50 <Greg_Noel>	Um, now I'm being called for lunch; gotta go.  Cul?
 545 11:27:55 <bdbaddog2007>	So punt until next bug party. 
 546 11:28:08 <bdbaddog2007>	I'll likely be on later.. thanks again for arranging.
 547 11:28:12 <Greg_Noel>	Hmmm... hang on.
 548 11:30:00 <bdbaddog2007>	hanging.. ;)
 549 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.
 550 11:30:55 <JimRandall>	few things in the world worth going hungry for :)
 551 11:31:10 <Greg_Noel>	But this may be one.  Can you stay?
 552 11:31:15 <bdbaddog2007>	true. sleep food water, all high on my priority lists.
 553 11:31:21 <JimRandall>	Aye, I can
 554 11:31:26 <bdbaddog2007>	sure.
 555 11:31:46 <Greg_Noel>	Azverkan, you really there?  Or is that a bot?
 556 11:31:54 <Azverkan>	its me
 557 11:32:03 <Azverkan>	slept in cause I had to work late and missed it
 558 11:32:16 <Greg_Noel>	So we still have a quorum.  Everybody want to go on?
 559 11:32:43 <bdbaddog2007>	sure. probably can go another 20 - 30 minutes.
 560 11:32:53 <JimRandall>	alrighty
 561 11:33:01 <bdbaddog2007>	so 1908 then?
 562 11:33:35 <Greg_Noel>	yes.
 563 11:33:54 <Greg_Noel>	Nice idea, but I don't see use case.
 564 11:34:30 <JimRandall>	Where I'd use it is in helping to track down cache corruption
 565 11:34:47 <Greg_Noel>	Happen often?
 566 11:34:59 <JimRandall>	Once every couple of months or so
 567 11:35:09 <JimRandall>	Sometimes once a month when things get busy
 568 11:35:12 <JimRandall>	Still not sure why
 569 11:35:27 <Greg_Noel>	How big a cache?  Simple to just blow it away and recache.
 570 11:36:15 <JimRandall>	Not sure exact size.  Difference between cached and uncached builds is about 30-40 minutes or so, which is significant
 571 11:36:36 *	Mikamikem (n=mikamike@216.111.90.27) has joined #scons
 572 11:36:45 <Greg_Noel>	Once a month?
 573 11:37:04 <Mikamikem>	has anyone ever set up a sconstruct file that has multiple environments and multiple configuration contexts before?
 574 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"
 575 11:37:55 <Greg_Noel>	I haven't looked at it; what does the patch fix?
 576 11:37:56 <bdbaddog2007>	I guess if the patch is there, 1.x
 577 11:38:23 <JimRandall>	patch implements it, I believe
 578 11:38:58 <Greg_Noel>	But if the problem is some timing issue, it really doesn't fix the base issue.
 579 11:39:06 <JimRandall>	Haven't looked at the patch myself, but Benoit usually good
 580 11:39:17 <bdbaddog2007>	I'm looking at patch now.
 581 11:39:17 <JimRandall>	Agreed.   and I'd fix the base issue if I knew what it was :)
 582 11:39:50 <Greg_Noel>	ok, Jim you want to contact Benoit and see if he has any insight?
 583 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
 584 11:40:12 <bdbaddog2007>	I added a note to bug on 4/8 requesting use model.
 585 11:40:27 <bdbaddog2007>	mark it research ?
 586 11:40:49 <Greg_Noel>	If it's just for debugging a real problem and has no other use, ...
 587 11:41:09 <Greg_Noel>	... I'd assign it to Jim to talk to Benoit, ...
 588 11:41:18 <bdbaddog2007>	ok sounds good.
 589 11:41:35 <Greg_Noel>	... and see if we can just go to the base issue and fix the timing ...
 590 11:41:52 <Greg_Noel>	... no sense to add this just to decorate the command line ...
 591 11:41:55 <JimRandall>	I don't know if that's what's happening for him 
 592 11:42:11 <Greg_Noel>	... and then remove it when debugging is done.
 593 11:42:15 <bdbaddog2007>	so research, Jim,  and move on then?
 594 11:42:19 <Greg_Noel>	ok,
 595 11:42:54 <bdbaddog2007>	1909, is the daemon thing. future seems to be consensus?
 596 11:43:00 *	Paf (n=Gedeon@c-76-21-119-149.hsd1.ca.comcast.net) has joined #scons
 597 11:43:18 <Greg_Noel>	yes, what priority?
 598 11:43:30 <Greg_Noel>	p4?  p5?
 599 11:43:54 <bdbaddog2007>	steven sugguested p3, I'd be fine with that, could be really useful.
 600 11:44:42 <Greg_Noel>	;-} I disagree with Steven; I think 'zero change' performance improvement will make these go away.
 601 11:44:59 <bdbaddog2007>	p4 and next then?
 602 11:45:06 <Greg_Noel>	good-o
 603 11:45:32 <bdbaddog2007>	1910 seems 1.x consensus
 604 11:45:57 <Greg_Noel>	1910, now four votes; enough for consensus; move on?
 605 11:46:02 <bdbaddog2007>	yup.
 606 11:46:34 <Greg_Noel>	1911
 607 11:47:01 <bdbaddog2007>	I see Brandon is adding to spreadsheet just ahead of discussion.. ;)
 608 11:47:22 <Azverkan>	1911 sounds like we need a partial test case to resolve
 609 11:47:26 <Greg_Noel>	Close enough...  looks like consensus 1.x
 610 11:47:43 <bdbaddog2007>	yes.
 611 11:47:54 <Greg_Noel>	Put Brandon on it?  {;-}
 612 11:49:11 <bdbaddog2007>	sounds good to me.
 613 11:49:14 <bdbaddog2007>	1913
 614 11:49:22 <bdbaddog2007>	1.0 seems to be consensus
 615 11:49:41 <Greg_Noel>	done
 616 11:50:19 <Greg_Noel>	1914
 617 11:50:34 <JimRandall>	caused by subst playing fast and loose with spaces I think
 618 11:51:53 <JimRandall>	can "fix" is by not using subst to expand the env variable
 619 11:52:03 <JimRandall>	changing subst would be more involved :)
 620 11:52:09 <Greg_Noel>	Indeed.  If it's as simple as just fetching the env var directly...
 621 11:52:28 <Greg_Noel>	Jim, you interested?
 622 11:52:40 <JimRandall>	Sure.  Can't directly test it, as I don't have that tool chain, but can test a proxy.
 623 11:53:29 <bdbaddog2007>	ok guys. I've gotta leave now. 
 624 11:54:19 <Greg_Noel>	ok, I'll make it yours.
 625 11:54:48 <Greg_Noel>	Bill, cul.
 626 11:54:54 <bdbaddog2007>	l8r
 627 11:54:58 <JimRandall>	have fun
 628 11:54:58 *	bdbaddog2007 has quit ("Leaving.")
 629 11:55:22 <Greg_Noel>	I'm losing track; who's still here?
 630 11:55:37 <JimRandall>	*wave*
 631 11:55:38 <Azverkan>	me
 632 11:57:34 <Greg_Noel>	1915?
 633 11:58:37 <Azverkan>	matching search path ordering with every compiler in existence is not possible
 634 11:59:04 <Azverkan>	need to support of some number of high profile ones and document differences in behavior for the rest
 635 11:59:34 <Greg_Noel>	Yeah, but I don't see that as a documentation bug.
 636 12:02:29 <Greg_Noel>	ok, Bill wants it; we'll give it to him and see what he finds.  That work?
 637 12:02:29 <Azverkan>	reply to submitter and ask for more info, otherwise invalid then?
 638 12:02:43 <Azverkan>	yep
 639 12:02:49 <Greg_Noel>	ok, next.
 640 12:03:14 <Greg_Noel>	1916, consensus
 641 12:03:36 <Greg_Noel>	1918, give to Steven?
 642 12:03:56 <JimRandall>	sounds good - hopefully is fixed.
 643 12:04:24 <Greg_Noel>	1920, Gary was following this, so I don't know the status.
 644 12:05:23 <Greg_Noel>	Steven says give it to Gary; I'll go along with that.
 645 12:05:40 <JimRandall>	Aye
 646 12:06:00 <Greg_Noel>	1.x?
 647 12:06:48 <JimRandall>	I guess.  I'm so the wrong person to say - not really planning on using it myself :)
 648 12:07:09 <Greg_Noel>	It can always be pushed.  Next?
 649 12:07:46 <JimRandall>	Getting to a long string of entries here that I'm not going to be much help on
 650 12:08:08 <Greg_Noel>	1921, invalid?
 651 12:08:17 <JimRandall>	aye
 652 12:08:54 <Azverkan>	yep
 653 12:09:06 <JimRandall>	And brandon's editing away there is almost like he's in the chat :)
 654 12:09:15 <Azverkan>	I would like to see it addressed at some point in the future but probably not before 2.x
 655 12:09:31 <Azverkan>	(or 3.x)
 656 12:09:51 <Greg_Noel>	Yeah.  Brandon, you make an interesting point about it being depends instead of dup.
 657 12:10:06 <JimRandall>	Azverkan == Brandon?
 658 12:10:12 <Azverkan>	yea
 659 12:10:19 <JimRandall>	aha :)
 660 12:10:20 <Greg_Noel>	Yeah, I initially thought it was Ken but I sussed it out. {;-}
 661 12:11:47 <Greg_Noel>	There's a similar FORTRAN issue later; wonder if they should be dups or depends?
 662 12:12:39 <Azverkan>	I come from the moz project where depends are used all the time
 663 12:12:56 <Azverkan>	and dups is from submitters who didn't find the bug in the db before posting
 664 12:13:04 <Greg_Noel>	Yeah, I agree; I'll go with that.
 665 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.
 666 12:14:05 <Greg_Noel>	ok, depends.  next?
 667 12:14:16 <JimRandall>	afk a sec
 668 12:15:05 <Greg_Noel>	1924 now has a consensus of 1.x
 669 12:15:11 <Greg_Noel>	next?
 670 12:16:12 <Azverkan>	dont really understand what the next one is trying to solve
 671 12:16:23 <Greg_Noel>	1925
 672 12:16:37 <Azverkan>	yeah
 673 12:17:18 <Greg_Noel>	He wants internal names to be relative, so he can move them wholesale.
 674 12:17:37 <Greg_Noel>	Useful in an install tree, for example, instead of full paths.
 675 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
 676 12:19:56 <Greg_Noel>	Hold for next time, so Steven can comment?
 677 12:20:13 <Azverkan>	fine with me
 678 12:20:39 <Greg_Noel>	done
 679 12:21:19 <Greg_Noel>	1926, pilot error?
 680 12:22:18 <JimRandall>	kinda sounds like it
 681 12:23:08 <Greg_Noel>	I'll take it and be sure.
 682 12:23:59 <JimRandall>	up to 1932 seem to be all fortran, with 1.0 consensus
 683 12:24:12 <Greg_Noel>	1927 through 1932 have been assigned to David
 684 12:24:26 <Greg_Noel>	1933?
 685 12:25:01 <JimRandall>	marked as fixed
 686 12:25:15 <Greg_Noel>	Um, it seems to me I just saw it go by as fixed
 687 12:25:29 <Greg_Noel>	ok, next?
 688 12:25:40 <JimRandall>	1937 dup and fixed
 689 12:26:10 <Greg_Noel>	ok, next
 690 12:26:29 <JimRandall>	1940 future p3 consensus, and seems reasonable to me
 691 12:26:55 <Greg_Noel>	ok, next?
 692 12:27:24 <JimRandall>	1941 - future taskmasterNG, yes?
 693 12:27:35 <Greg_Noel>	1941 also future consensus
 694 12:28:07 <Greg_Noel>	uh, it may resurface before then, but yes.
 695 12:28:58 <Greg_Noel>	1944?
 696 12:29:31 <Greg_Noel>	Bill wants it; give it to him.
 697 12:29:43 <JimRandall>	sounds good to me
 698 12:30:16 <Azverkan>	yeah
 699 12:30:26 <Greg_Noel>	1945?
 700 12:30:29 <JimRandall>	1945 - part of the problem is being caused by a different bug
 701 12:30:55 <Greg_Noel>	which?
 702 12:31:32 <JimRandall>	hrm, one sec - not sure If I'm right about that
 703 12:32:18 <JimRandall>	in his 2nd para, why is scons complaining?
 704 12:33:00 <Azverkan>	which 2nd para
 705 12:33:02 <Azverkan>	op or ken?
 706 12:33:17 <JimRandall>	ken
 707 12:33:48 <Azverkan>	sounds like exists vs lexists mismatch?
 708 12:34:32 <Greg_Noel>	Are you on 1945?
 709 12:34:38 <JimRandall>	I thought so
 710 12:34:52 <JimRandall>	Seemed odd to be complaining about an implicit dependency at all
 711 12:35:03 <Azverkan>	err no
 712 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
 713 12:36:03 <JimRandall>	Nope, I'm on the wrong track - ignore me :)
 714 12:36:18 <Greg_Noel>	Apparently, the directory scanner caches, but doesn't have a decider to determine when to rescan.
 715 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.
 716 12:38:41 <Greg_Noel>	I see a lot of 1.x suggested; maybe 1.x p2?  Or p1?
 717 12:39:31 <JimRandall>	Aye.   Seems like it'd make it impossible to use dir scanners and implicit at the same time
 718 12:39:47 <Greg_Noel>	Brandon?
 719 12:40:01 <JimRandall>	which would effectively make dir scanners a lot less useful
 720 12:40:19 <Azverkan>	I haven't used implicit cache in years so no comment
 721 12:40:35 <Greg_Noel>	ok, 1.x p1?  Jim?
 722 12:40:46 <JimRandall>	Sure thing
 723 12:40:49 <Greg_Noel>	done
 724 12:41:01 <Greg_Noel>	1946, lexists?
 725 12:42:39 <JimRandall>	haven't read the gsoc, but punting until 2.x seems OK to me
 726 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.
 727 12:43:36 <Greg_Noel>	1949?
 728 12:43:55 <Azverkan>	hold for bill
 729 12:44:39 <Greg_Noel>	Probably also a dependency of 1086, batch builders.
 730 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
 731 12:44:54 <Azverkan>	if Bill has found one he would be the best to comment
 732 12:45:04 <Greg_Noel>	ok, hold.
 733 12:45:13 <Azverkan>	I dont think its a batch builder related issue tho
 734 12:45:21 <Greg_Noel>	1950?
 735 12:45:48 <Greg_Noel>	Yes, batch builder must deal with circular dependencies to create best batch.
 736 12:47:22 <Greg_Noel>	1950, invalid.  If Bill objects, he can reopen.
 737 12:48:07 <JimRandall>	Aye, I missed the Builder part at first too
 738 12:49:08 <Greg_Noel>	Brandon, a test case for a timing issue that surfaces rarely?  Surely you jest! {;-}
 739 12:49:41 <Azverkan>	someone probably has an open source project somewhere that it surfaces in?
 740 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.
 741 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.
 742 12:54:04 <Azverkan>	This type of issue might be easier to track down with scons running on a non cPython version of Python
 743 12:54:25 <Azverkan>	not sure how to find the bug without auditing the code
 744 12:55:54 <JimRandall>	Sorry guys - I'm going to have to take off
 745 12:56:29 <JimRandall>	good luck with the triage
 746 12:56:39 <Greg_Noel>	Yeah, and the dog is asking for his walk; I need to go, too.
 747 12:56:50 <Greg_Noel>	Time to quit, I think.
 748 12:57:00 <Azverkan>	same
 749 12:57:07 <JimRandall>	have fun all
 750 12:57:10 <Greg_Noel>	ok, cul.
 751 12:57:16 <Azverkan>	later

BugParty/IrcLog2008-04-12 (last edited 2008-04-24 02:19:54 by ip68-7-76-16)