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 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)