1 16:43:36 *	jason_at_intel (~chatzilla@220.sub-75-207-216.myvzw.com) has joined #SCONS
   2 16:54:35 *	garyo (~garyo@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has joined #SCONS
   3 17:02:56 *	sgk (~sgk@nat/google/x-zskmujhtignuxavr) has joined #SCONS
   4 17:03:07 <sgk>	hello, who's here?
   5 17:03:11 <garyo>	Hi Steven
   6 17:03:13 <jason_at_intel>	Hi Steve!
   7 17:03:55 <sgk>	hi guys
   8 17:04:03 *	sgk struggles with getting his windows arranged properly
   9 17:04:42 *	garyo is on a tiny screen laptop, everything's maximized all the time
  10 17:04:20 <sgk>	whew!  okay
  11 17:04:42 <sgk>	GregNoel here?
  12 17:05:03 <garyo>	Haven't heard from him yet
  13 17:05:27 <sgk>	no bdbaddog either
  14 17:09:22 <GregNoel>	I'm here, but I can't stay long...
  15 17:09:32 <garyo>	Hi Greg -- let's get going then.
  16 17:09:52 <sgk>	let's get going then, fortunately not too many bugs tonight
  17 17:09:52 <garyo>	Let's start w/ 2674 I think
  18 17:10:26 <sgk>	2674:  defer to next time to see if the OP comes up with anything?
  19 17:10:38 <GregNoel>	yes, 2674...  seems like consensus to defer
  20 17:10:34 <garyo>	agreed.
  21 17:10:44 <GregNoel>	done
  22 17:10:53 <GregNoel>	2675
  23 17:11:01 <garyo>	2675 is either bill or me I think
  24 17:11:15 <garyo>	I think Bill was talking to this guy on the list
  25 17:11:28 <sgk>	yeah, i'd say bdbaddog unless you're really itching to tackle it
  26 17:11:39 <garyo>	not at the moment :-/
  27 17:11:45 <sgk>	fair enough :-)
  28 17:11:51 <GregNoel>	priority and milestone?
  29 17:11:55 <sgk>	research bdbaddog?
  30 17:12:17 <garyo>	or just 2.1 p3, I think msvc issues are important
  31 17:11:57 <jason_at_intel>	I don't think that it should be done
  32 17:12:24 <garyo>	jason, huh?
  33 17:12:34 <sgk>	jason_at_intel:  why not?
  34 17:12:34 <garyo>	(oh, the fallback)
  35 17:12:42 <jason_at_intel>	Ya fallback
  36 17:12:42 <sgk>	garyo:  why not?
  37 17:12:53 <jason_at_intel>	if you say 64-bit build that .. not 32-bit
  38 17:13:19 <jason_at_intel>	fallback is dangerous
  39 17:13:31 <jason_at_intel>	people will get stuff they don't expect
  40 17:13:34 <sgk>	is this config explicitly saying 64-bit?  I thought the situation was that it was using a default
  41 17:13:33 <garyo>	I think it should be done. He's not specifying anything; scons should make a working exe with whatever compiler you have.
  42 17:13:41 <sgk>	what garyo said
  43 17:13:50 <sgk>	agree that if you explicitly configure 64-bit it should fail
  44 17:13:55 <garyo>	yes
  45 17:14:05 <jason_at_intel>	sure.. that is not so bad.. still has risk.
  46 17:14:27 <jason_at_intel>	but i will not push it :-)
  47 17:14:32 <sgk>	sure, but people who care about that risk have an easy way to do so:  configure the TARGET_ARCH
  48 17:14:26 <garyo>	so bdbaddog 2.1 p3?
  49 17:14:36 <sgk>	bdbaddog 2.1 p3
  50 17:14:50 <GregNoel>	done
  51 17:15:04 <GregNoel>	2676
  52 17:15:26 <garyo>	I submitted that just to record it.  3.x is fine w/ me.
  53 17:15:30 <jason_at_intel>	is this about the CPPDEFINES setup option?
  54 17:15:35 <sgk>	3.x sounds good
  55 17:15:45 <jason_at_intel>	agreed
  56 17:15:59 <garyo>	Basically yes, Jason -- CPPDEFINES is fixed, but there are other theoretical cases.
  57 17:16:58 <jason_at_intel>	right.. just checking my understanding
  58 17:16:06 <garyo>	ok
  59 17:16:25 <sgk>	3.x p4, don't need to fill in a name now?
  60 17:16:41 <garyo>	sgk: agree w/ 3.x p4 no name.
  61 17:16:56 <GregNoel>	garyo, what other than CPPDEFINES?  Remember, CPPDEFINES must also generate -DFOO=bar, so it's not necessarily typical.
  62 17:17:35 <garyo>	Greg: no actual cases I can think of now.  More a question of hardcoding CPPDEFINES in a few places where we should probably be more general.
  63 17:17:55 <GregNoel>	Ah, in that case I'm fine with 3.x p4
  64 17:18:09 <jason_at_intel>	I was thinking CPPFLAGS or LINK flags often have var=val
  65 17:18:41 <garyo>	But I don't think we handle dicts in either case there.
  66 17:18:56 <jason_at_intel>	true
  67 17:18:41 <jason_at_intel>	plus you could use it to help deal with linking static vs dynamic on unix
  68 17:19:08 <garyo>	yes, Bstatic/dynamic could be useful.  But changing it when we get there will not be hard.
  69 17:18:39 <sgk>	let's do 3.x p4, we can move it to research when we re-prioritize those
  70 17:16:26 <garyo>	2677 research sk?
  71 17:19:56 <sgk>	any dissent from research p2 sk?
  72 17:20:04 <garyo>	nope
  73 17:20:07 <jason_at_intel>	not here
  74 17:20:13 <GregNoel>	none, although I think allowing variant dirs to be under src dirs to be dangerous
  75 17:21:02 <garyo>	That would be a bit ... unusual.
  76 17:21:39 <GregNoel>	Note that there's one anomoloy (sp) in the treatment already; we don't need to make it worse.
  77 17:21:44 <sgk>	GregNoel:  i conceptually agree, i think it's more likely this ends up being a doc fix once I clear my head around it again
  78 17:21:20 <jason_at_intel>	I was under the view this was about having these values not under the SConstruct directory
  79 17:21:40 <garyo>	Jason: I think that's what it is about.  Build dir entirely elsewhere.
  80 17:22:29 <GregNoel>	Build dir outside top dir works fine; I use it all the time.
  81 17:22:55 <GregNoel>	but you must specify the directory; it's not built by default.
  82 17:22:24 <jason_at_intel>	it can be done... it just that relative paths don't work as expected here
  83 17:22:29 <jason_at_intel>	abs paths do
  84 17:23:13 <GregNoel>	If that's his problem, the bug is INVALID
  85 17:23:14 <sgk>	(almost shuttle time)
  86 17:23:28 <sgk>	GregNoel:  good point
  87 17:23:42 <jason_at_intel>	clarification needed?
  88 17:24:01 <GregNoel>	needs more info, so ask OP and defer?
  89 17:24:16 <jason_at_intel>	+1
  90 17:24:22 <sgk>	okay by me
  91 17:24:32 <sgk>	biab
  92 17:24:34 *	sgk has quit (Quit: sgk)
  93 17:24:55 <GregNoel>	2278
  94 17:25:15 *	GregNoel is just looking at this for the first time; give me a minute to research
  95 17:25:16 <garyo>	Defer a week to see if OP replies.
  96 17:26:37 *	sgk (~sgk@nat/google/x-vcwojyshrkoeayvj) has joined #SCONS
  97 17:26:48 <garyo>	Looks like some path needs to be canonicalized to remove ".." to me
  98 17:26:56 <garyo>	Hi Steven, just on 2278
  99 17:27:01 <GregNoel>	garyo, agree defer
 100 17:27:51 <jason_at_intel>	+1 defer and see if OP replies
 101 17:28:21 <GregNoel>	done
 102 17:28:37 <garyo>	OK, skip 2249 since it's bdbaddog's and he's not here?
 103 17:28:38 <GregNoel>	2249, no comments, so looks like defer again?
 104 17:29:00 <garyo>	yes
 105 17:29:14 <garyo>	2485 I think I understand now.
 106 17:29:43 *	sgk_ (~sgk@67.218.104.161) has joined #SCONS
 107 17:29:53 <garyo>	Configure() is updating the library node's signature, which makes it seem up to date.
 108 17:29:54 *	sgk has quit (Disconnected by services)
 109 17:29:57 *	sgk_ is now known as sgk
 110 17:30:21 <sgk>	okay, i think i'm back
 111 17:30:21 <garyo>	I suspect 2485 will be hard to fix.
 112 17:30:26 <garyo>	Hi again
 113 17:30:40 <jason_at_intel>	do you know what is going on?
 114 17:30:48 <garyo>	Steven, I'd appreciate it if you'd take a look at 2485 some time.
 115 17:30:48 <GregNoel>	Hmmm...  Side effect from BSR?
 116 17:30:54 <garyo>	What's BSR?
 117 17:31:03 <garyo>	(wait, I know)
 118 17:31:19 <garyo>	No, I think it's just a long-standing SConf bug.
 119 17:31:31 <garyo>	CheckLibrary() actually builds a test program and links it to that lib...
 120 17:31:46 <garyo>	which means the lib gets a Node and it gets updated when the test prog is built.
 121 17:32:06 <garyo>	Then the main world gets the wrong (updated) sig from the lib
 122 17:32:05 <GregNoel>	ah
 123 17:31:33 <sgk>	garyo:  put my name on it so it stays on the radar screen
 124 17:32:42 <garyo>	OK, I'll add your name.  Anyway I think it's out of research mode now, we should assign it a milestone/pri.
 125 17:32:52 <garyo>	I'm thinking 2.x p3
 126 17:33:13 <GregNoel>	worksforme
 127 17:33:25 <jason_at_intel>	+1
 128 17:33:36 <sgk>	yeah, throw it my way, 2.x p3 sounds good
 129 17:33:41 <GregNoel>	done
 130 17:33:52 <GregNoel>	2521
 131 17:34:18 <GregNoel>	no comments; defer again?
 132 17:34:19 <garyo>	skip again til bdbaddog is here
 133 17:34:41 <garyo>	2575
 134 17:35:06 <jason_at_intel>	I showed Steven the code i had
 135 17:35:20 <jason_at_intel>	I think i have an AR to write up something
 136 17:35:27 <jason_at_intel>	for discussion
 137 17:35:44 <garyo>	Sounds good -- we did decide on an API, right?
 138 17:36:25 <garyo>	Seemed clever to me at the time I remember.
 139 17:36:27 <GregNoel>	tuple(archive-name,real-name) as I recall.
 140 17:36:41 <garyo>	yes
 141 17:37:13 <jason_at_intel>	I was not sure we agreed on that
 142 17:37:14 <jason_at_intel>	but that was the idea greg pushed
 143 17:37:37 <garyo>	After he showed me how it solved all my cases I was convinced.
 144 17:37:48 <garyo>	... but that's just me.
 145 17:37:47 <jason_at_intel>	not sure how that would work with the current builders sources
 146 17:38:03 <garyo>	It can't be a regular builder.
 147 17:38:28 <garyo>	(e.g. arg2nodes wouldn't work on those tuples)
 148 17:38:32 <GregNoel>	I see that as a distinction without a difference ...but that's just me {;-}
 149 17:38:48 <garyo>	Steven: what do you think?
 150 17:39:11 <GregNoel>	garyo, actually, I think it does...  arg2nodes just ignores them
 151 17:39:28 <garyo>	hmm, cool
 152 17:39:03 <jason_at_intel>	Well i guess we want the zip like builder to be callable more than once
 153 17:39:29 <sgk>	i'm honestly not sure, tuples sound attractive from a flexibility standpoint
 154 17:39:41 <sgk>	but i haven't looked at this in any detail
 155 17:40:04 <jason_at_intel>	I ok with the idea
 156 17:40:17 <jason_at_intel>	I would then want to apply it to the copy builders
 157 17:40:41 <jason_at_intel>	 ie copy(Dir,[(as this,from this)]
 158 17:40:29 <garyo>	Good idea
 159 17:40:48 <garyo>	yup
 160 17:41:02 <sgk>	is the simple case still simple when using tuples?
 161 17:41:15 <sgk>	i.e. it doesn't require something like specifying all of the files individually
 162 17:41:19 <garyo>	Tuples are optional.  Regular node list still works.
 163 17:41:30 <garyo>	And dirs work either as nodes or in tuples.
 164 17:41:49 <garyo>	i.e. Zip(zipfile, [(todir, fromdir)]
 165 17:41:45 <jason_at_intel>	do we have a prototype builder doing this?
 166 17:41:59 <jason_at_intel>	I though Greg said he had sometime
 167 17:42:12 <GregNoel>	I'm being called away; have to leave in a couple of minutes
 168 17:42:13 <jason_at_intel>	I would like to see it myself, to use it as a template
 169 17:42:23 <garyo>	Greg said he had something working?
 170 17:42:25 <GregNoel>	Yes, I have code
 171 17:42:36 <GregNoel>	How should I make it available?
 172 17:42:39 <jason_at_intel>	can you share :-)
 173 17:43:20 <jason_at_intel>	This might be a nice way to solve my pattern issue in Parts ( or add tree structure ability in Glob)
 174 17:43:20 <garyo>	just email it?
 175 17:43:31 <garyo>	or wiki page?
 176 17:43:34 <GregNoel>	works; got to go
 177 17:43:40 <garyo>	ok, c u later
 178 17:43:45 <jason_at_intel>	latter greg!
 179 17:43:49 <GregNoel>	I'll leave my session open and read the rest later.  Bye, all.
 180 17:43:58 <garyo>	ok, I think we're mostly done though
 181 17:44:09 <sgk>	later
 182 17:44:28 <jason_at_intel>	cool.. so defer 2575 till Gregs sample can be reviewed?
 183 17:44:41 <sgk>	yeah, we really don't have any more in the spreadsheet
 184 17:44:53 <garyo>	Jason: I agree w/ that.
 185 17:45:07 <garyo>	Then we'll turn it into a regular ticket to implement it.
 186 17:45:24 <sgk>	yeah, that sounds good
 187 17:45:24 <sgk>	any other issues to discuss?
 188 17:45:28 <jason_at_intel>	I will apply to some stuff in Parts as well, once i get the feel for it
 189 17:45:37 <garyo>	I'm going to sign off if there's nothing else.
 190 17:45:51 <garyo>	bye 4 now
 191 17:45:54 <jason_at_intel>	not at the moment
 192 17:45:55 *	garyo (~garyo@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has left #SCONS
 193 17:47:39 <jason_at_intel>	till next time
 194 17:47:43 <sgk>	later
 195 17:47:46 *	sgk (~sgk@67.218.104.161) has left #SCONS
 196 17:47:46 <jason_at_intel>	cool
 197 17:48:05 *	jason_at_intel has quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.6/20100625231939])
 198 

BugParty/IrcLog2010-08-24 (last edited 2010-09-06 17:27:18 by ip68-7-79-188)