Please note:The SCons wiki is now restored from the attack in March 2013. All old passwords have been invalidated. Please reset your password if you have an account. If you note missing pages, please report them to webmaster@scons.org. Also, new account creation is currently disabled due to an ongoing spam flood (2013/08/27).
   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)