Please note:The SCons wiki is in read-only mode due to ongoing spam/DoS issues. Also, new account creation is currently disabled. We are looking into alternative wiki hosts.
   1 17:18:01 *	Jason_at_intel (n=chatzill@bementil-116.illinois.prairieinet.net) has joined #scons
   2 17:27:59 *	GregNoel is no longer marked as being away
   3 17:28:16 *	garyo-home (n=chatzill@209-6-158-38.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has joined #scons
   4 17:30:22 *	stevenknight (n=stevenkn@67.218.107.49) has joined #scons
   5 17:30:30 *	stevenknight is now known as sgk_
   6 17:30:40 <GregNoel>	Hi, guys
   7 17:30:49 <sgk_>	hey
   8 17:31:07 <GregNoel>	right on time; looks like everybody's here
   9 17:31:19 <garyo-home>	hlo
  10 17:31:58 <garyo-home>	shall we dive in with 804?
  11 17:32:22 <sgk_>	804:  defer again?
  12 17:32:26 <sgk_>	only half joking...
  13 17:32:26 <GregNoel>	I think we should tackle 804 and 2404 as a pair.  Even if it's not the same problem, they're both related to lazy actions; it makes sense for only one person to have to open the code.
  14 17:32:41 <sgk_>	agree w/GN
  15 17:32:45 <sgk_>	re: one person
  16 17:32:46 <garyo-home>	makes sense.
  17 17:33:59 <garyo-home>	I suggest for 804 and 2404 we assign to research/Bill; they're low pri so if he doesn't get to them soon, no problem.
  18 17:34:17 <sgk_>	sounds good to me
  19 17:34:32 <GregNoel>	p3 or p4?
  20 17:34:37 <garyo-home>	p4
  21 17:34:38 <sgk_>	although it goes a little against the idea of "research" being a triage-soon-for-reclassification bucket
  22 17:34:42 <sgk_>	p4
  23 17:34:47 <sgk_>	GN, you okay with it?
  24 17:34:49 <GregNoel>	done
  25 17:34:49 <sgk_>	research p4
  26 17:34:52 <sgk_>	done
  27 17:35:06 <GregNoel>	2409, consensus
  28 17:35:20 <GregNoel>	2406, consensus
  29 17:35:31 <GregNoel>	2408, consensus
  30 17:35:41 <sgk_>	rockin'...
  31 17:36:03 <GregNoel>	2410, who, but otherwise consensus
  32 17:37:00 <garyo-home>	I've already got two from this spreadsheet, but this one is *so* easy...
  33 17:37:12 <GregNoel>	I guess I'll take it.
  34 17:37:16 <garyo-home>	thx
  35 17:37:25 <GregNoel>	done
  36 17:37:27 <sgk_>	thank you...
  37 17:37:35 <GregNoel>	2410
  38 17:37:43 <sgk_>	give it to me
  39 17:37:49 <sgk_>	this and the next are a google guy
  40 17:37:54 <sgk_>	i'll thump on him for filing lousy bug reports
  41 17:38:05 <garyo-home>	:-)
  42 17:38:07 <GregNoel>	I was thinking the same thing...
  43 17:38:29 <GregNoel>	ok, 2.x p3 sk, done
  44 17:38:40 <garyo-home>	agreed.
  45 17:38:43 <sgk_>	no context to the diffs, no problem description...  sheesh, the people that company will stoop to hiring...
  46 17:38:55 <garyo-home>	lol
  47 17:39:00 <GregNoel>	{;-}
  48 17:39:25 <sgk_>	2413
  49 17:39:34 <garyo-home>	2414, xml output: wontfix, suggest posting on wiki
  50 17:39:35 <sgk_>	er
  51 17:39:36 <sgk_>	2414
  52 17:39:47 <sgk_>	i like that even better than future
  53 17:40:01 <GregNoel>	agreed
  54 17:40:02 <sgk_>	seems like "xml outputter" is just too vague and generic
  55 17:40:18 <sgk_>	done
  56 17:40:21 <GregNoel>	done
  57 17:40:40 <sgk_>	2415
  58 17:40:52 <garyo-home>	2.x/p2/ludwig
  59 17:41:10 <garyo-home>	or 1.3, either one
  60 17:41:15 <sgk_>	ok with assigning to Ludwig, me as backup if he's AWOL?
  61 17:41:21 <GregNoel>	OK, but I'll say that he can reassign it to sk
  62 17:41:21 <garyo-home>	yes.
  63 17:41:21 *	bdbaddog (n=chatzill@adsl-71-142-86-81.dsl.pltn13.pacbell.net) has joined #scons
  64 17:41:28 <sgk_>	agreed
  65 17:41:33 <garyo-home>	Hi, Bill.
  66 17:41:37 <bdbaddog>	Hi
  67 17:41:39 <sgk_>	hey bill
  68 17:41:46 <Jason_at_intel>	wow step away for a minute and you are all are almost done
  69 17:41:47 <sgk_>	2415:  done
  70 17:41:50 <sgk_>	2416
  71 17:42:06 <garyo-home>	Hi Jason, big crowd tonight!
  72 17:42:19 <Jason_at_intel>	I see .. that is good :-)
  73 17:42:29 <GregNoel>	I  don't think 2316 is lazy action; it's failure to substitute the target
  74 17:42:33 <garyo-home>	2416: guess I'll take it, at least I'll look at it.
  75 17:42:47 <garyo-home>	I know the subst code pretty well.
  76 17:42:42 <GregNoel>	research or anytime?
  77 17:42:54 <garyo-home>	research is a good idea.
  78 17:42:56 <GregNoel>	done
  79 17:43:09 <GregNoel>	2417: Gary, a return code of -1 means "command not found" (at least in this case)
  80 17:43:36 <GregNoel>	Same failure in packaging tests; I don't know why it can't find "rm".
  81 17:44:20 <GregNoel>	I wonder about a missing PATH
  82 17:43:46 <garyo-home>	Really?
  83 17:43:55 <sgk_>	GregNoel:  if zsh is well-behaved
  84 17:44:35 <sgk_>	yeah, that packaging test failure is a real pain
  85 17:44:42 <sgk_>	i took a quick look once but nothing obvious
  86 17:44:47 <sgk_>	PATH (as reported by buildbot) looks good
  87 17:44:50 <garyo-home>	I use zsh daily on Mac, Linux and Windows.  I'll try it, but it'll work fine.  Give it to me for research, I'll get more info from the OP.
  88 17:45:02 <GregNoel>	done
  89 17:45:05 <sgk_>	s/packaging test/packaging buildbot step/
  90 17:45:17 <sgk_>	done
  91 17:45:34 <sgk_>	2418:  me, +vs_revamp
  92 17:45:55 <GregNoel>	Really?  Sure.
  93 17:45:56 <sgk_>	or maybe +VisualStudio, we're still using that keyword, right?
  94 17:46:37 <GregNoel>	I just put "v" in the box and Firefox finds the right one
  95 17:46:13 <garyo-home>	not +VisualStudio, that's for *building* VS solution files.
  96 17:46:19 <garyo-home>	(iirc)
  97 17:46:20 <sgk_>	okay
  98 17:46:26 <sgk_>	that sounds right
  99 17:46:46 <garyo-home>	:-/
 100 17:46:53 <Jason_at_intel>	does this reproduce?
 101 17:47:07 <Jason_at_intel>	I just tested this.. and it works for me
 102 17:47:08 <garyo-home>	Jason: what, 2418?
 103 17:47:15 <Jason_at_intel>	yes
 104 17:47:23 <garyo-home>	hey, maybe it's already fixed then.
 105 17:47:26 <Jason_at_intel>	i assumed cache means that it woudl not rebuild
 106 17:48:02 <garyo-home>	it's more complex than that.  See the bug report.
 107 17:48:15 <Jason_at_intel>	ok
 108 17:48:02 <sgk_>	aha
 109 17:48:08 <sgk_>	light just went on
 110 17:48:23 <garyo-home>	sgk: ?
 111 17:48:36 <sgk_>	i was misreading the problem
 112 17:48:59 <garyo-home>	Is it that they aren't sideeffects or something?
 113 17:49:19 <garyo-home>	or side effects don't get retrieved maybe?
 114 17:49:23 <Jason_at_intel>	ahhh
 115 17:48:58 <sgk_>	yeah, it would be good to retrieve the .pdb from cache, too
 116 17:49:25 <sgk_>	but retrieving multiple target files from CacheDir with the same "build signature" isn't supported right now
 117 17:50:14 <sgk_>	so it would involve some design work to support
 118 17:50:18 <garyo-home>	ok, so maybe not +vs_revamp after all, but 3.x?  Your call...
 119 17:50:26 <sgk_>	yeah, 3.x
 120 17:50:35 <GregNoel>	priority?
 121 17:50:50 <sgk_>	p2 or p3
 122 17:51:01 <sgk_>	it's one of those things that's grating because we *should* be smart about it
 123 17:51:08 <GregNoel>	p2 then
 124 17:51:10 <sgk_>	but it's not clear how widespread a problem it really is in practice
 125 17:51:16 <garyo-home>	p3 then :-)
 126 17:51:27 <sgk_>	:-)
 127 17:51:27 <GregNoel>	{;-}
 128 17:51:30 <garyo-home>	(I don't really care, just being snarky)
 129 17:51:42 <sgk_>	go with p2
 130 17:51:46 <GregNoel>	done
 131 17:51:58 <GregNoel>	2319, consensue
 132 17:52:03 <GregNoel>	2420
 133 17:52:33 <sgk_>	Rob, me as backup if he's AWOL
 134 17:52:34 <sgk_>	2.x p3
 135 17:53:08 <GregNoel>	done; I'll add you as cc
 136 17:53:14 <garyo-home>	sounds good
 137 17:53:26 <sgk_>	2421:  garyo++
 138 17:53:32 <GregNoel>	++
 139 17:53:40 <garyo-home>	(well of course I broke it first...)
 140 17:53:50 <garyo-home>	but thx.
 141 17:53:54 <GregNoel>	(that's why I gave it to you)
 142 17:54:11 <GregNoel>	That's the issues; report on 1.3?
 143 17:54:37 <sgk_>	i've still been out of it;  bill, yt?  any progress?
 144 17:54:51 <sgk_>	bdbadog?
 145 17:54:55 <sgk_>	bdbaddog?
 146 17:55:11 <bdbaddog>	sorry distracted by my wife.. ;)
 147 17:55:38 <garyo-home>	I have one 1.3 bug I've still been working on but it's much more complicated than I'd thought when I started it, 2048.  May need to get deferred.
 148 17:55:53 <bdbaddog>	o.k. so I'm behind on that, but looks like I need to shuffle some logic around to make it not too messy for the HOST_* and TARGET_* initialization.
 149 17:56:20 <Jason_at_intel>	does 1.3 get vs vs_revamp
 150 17:56:34 <sgk_>	Jason_at_intel:  yes
 151 17:56:34 <bdbaddog>	Seems like that logic should be in the Platform/*.py code.
 152 17:56:35 <garyo-home>	That's the plan right now anyway.
 153 17:56:40 <sgk_>	the pacing item is merging vs_revamp to trunk
 154 17:56:53 <Jason_at_intel>	gary: what about the extra vars in MSVS you complained about?
 155 17:57:12 <garyo-home>	btw, I'm using vs_revamp (latest trunk) successfully at work w/ VS2003 and 2005.  Thanks for some well-placed help, Jason.
 156 17:58:05 <Jason_at_intel>	no problem.. I have  new version almost done of this... should address the need to redo this code everytime we add a new version
 157 17:58:20 <Jason_at_intel>	I'll post when done
 158 17:58:37 <garyo-home>	more table-driven?
 159 17:59:03 <sgk_>	bdbaddog:  any pieces where you could use help?
 160 17:59:20 <bdbaddog>	So the issue at hand with the HOST/TARGET variable initialization in Platform/*.py is that the Environment() isn't initialized prior to the environment being initialized (if I remember correctly)
 161 18:00:11 <bdbaddog>	And I wanted to bounce it off of at least 1 other person prior to coding it up.
 162 18:00:33 <sgk_>	profitable to do it here?  or take it off line?
 163 18:02:47 <bdbaddog>	I'll bow to the wisdom of others. if there are other topics to discuss, then we can do it another time.
 164 18:03:08 <GregNoel>	Nothing but time tonight; Steven is pacer on the shuttle
 165 18:03:10 <sgk_>	i think this is the main topic -- GN, you have anything else to go over?
 166 18:03:23 <GregNoel>	nope
 167 18:03:34 <sgk_>	~10-15 minutes to shuttle stop
 168 18:03:48 <garyo-home>	I'm happy to listen
 169 18:04:01 <bdbaddog>	Lemme find the code in question.
 170 18:04:09 *	vsmatck has quit (kubrick.freenode.net irc.freenode.net)
 171 18:04:09 <bdbaddog>	Do you all have vs_revamp checked out?
 172 18:04:24 <GregNoel>	One aside: For what it's worth, I've got an update of PlatformToolConfig that focuses on the platform configuration phase.  The tool part of it isn't anywhere near complete, though.  Should I push it over for your comments?
 173 18:04:27 <Jason_at_intel>	I am interest if nothing else to learn more of the insides of Scons
 174 18:04:53 <sgk_>	i do
 175 18:04:57 <sgk_>	updating...
 176 18:05:13 <Jason_at_intel>	updated
 177 18:05:14 <bdbaddog>	I can't remember off the top of my head where Platform is initialized. anyone?
 178 18:05:34 <GregNoel>	Platform/__init__.py
 179 18:06:59 <bdbaddog>	Scons.Platform.Platform() is called from somewhere. that's the where I'm looking for.
 180 18:07:25 <bdbaddog>	But if you look at Platform/__init__.py Platform()
 181 18:08:16 <bdbaddog>	you'll see it returns a PlatformSpec, and then assigns the platform module.generated to the __call__
 182 18:08:58 <sgk_>	ah
 183 18:09:00 <bdbaddog>	So then is the generated in win32.py the right place to populated the HOST_CPU, and HOST_OS
 184 18:09:09 <bdbaddog>	I mean generate() in win32.py
 185 18:09:47 <bdbaddog>	Also I wanted to move get_architecture() from Tools/MSCommon/arch.py to win32.py
 186 18:10:12 <sgk_>	i think the generate() in win32.py
 187 18:10:23 <bdbaddog>	In which case the generate() for each platform should set the HOST_OS/CPU and TARGET_{OS|CPU} as well.
 188 18:10:24 <sgk_>	(and in the other platform-speciific modules)
 189 18:10:33 <Jason_at_intel>	HOST_ARCH? or HOST_CPU
 190 18:10:51 <bdbaddog>	I think we decided HOST_CPU to leverage autoconf/auto* nomenclature.
 191 18:11:05 <sgk_>	yes, HOST_CPU for exactly that reason
 192 18:11:32 <Jason_at_intel>	I thought it was the other way.. as x86_64 is an architecture not a CPU
 193 18:11:40 <bdbaddog>	So does that sound like a reasonable reorganization of the code?
 194 18:11:47 <GregNoel>	(Actually, I argue it should set PLATFORM_{CPU,VENDOR,KERNEL,OS} since it could be different in different Environment()s.)
 195 18:11:48 <sgk_>	why move get_architecture()?  win32.py implies an OS
 196 18:11:58 <sgk_>	i was thinking our mapping was arch => cpu
 197 18:11:58 <bdbaddog>	Jason: Hmm it's a cpu family
 198 18:12:06 <bdbaddog>	get_architecture is os specific logic.
 199 18:12:14 <bdbaddog>	at least for win32, it's only for win32.
 200 18:12:38 <Jason_at_intel>	that is fine.. just worried about people wanting a AMD64 CPU or an INTEL64 CPU
 201 18:12:49 <sgk_>	oh, right, because of looking for the magic PROCESSOR__ARCHIT* variables
 202 18:12:53 <sgk_>	okay, makes sense
 203 18:13:11 <sgk_>	GregNoel:  PLATFORM_* ?
 204 18:13:12 <bdbaddog>	plus the tools aren't initialized yet.
 205 18:13:17 <Jason_at_intel>	Greg: ya.. so I did not push the otehr two as i can't find a build use for them.. only a packing use.. I took what was safe
 206 18:13:23 <sgk_>	we were converging on HOST_* and TARGET_*
 207 18:13:24 <Jason_at_intel>	not that it woudl not be added on later
 208 18:13:41 <garyo-home>	I like HOST and TARGET_*.
 209 18:13:42 <bdbaddog>	and that allows us to have (eventually) the platform logic set the default tools lists
 210 18:14:44 <sgk_>	we're also converging on _{CPU,VENDOR,KERNEL,OS} suffixes to ride GNU's coattails
 211 18:14:54 <Jason_at_intel>	I thought HOST_ARCH was the "high level" cpu and CPU was the low level
 212 18:15:02 <GregNoel>	In general, whatever (cross-)compiler you want to invoke, it runs on the current platform, so you shouldn't really need the detailed specifics.  Only for what you're generating.  And PLATFORM_* makes sense for that.
 213 18:15:33 <sgk_>	sorry, i don't understand that
 214 18:15:43 <Jason_at_intel>	which one?
 215 18:15:48 <sgk_>	PLATFORM_ seems ambiguous to me
 216 18:15:49 <garyo-home>	google HOST_ARCH: 3960 results.  google HOST_CPU: 59,700 results.
 217 18:15:55 <sgk_>	HOST_* and TARGET_* seem obvious
 218 18:16:07 <bdbaddog>	+1 HOST_ and TARGET_
 219 18:16:23 <garyo-home>	+1 HOST_ and TARGET_
 220 18:16:26 <Jason_at_intel>	but these don't map to auto config... i say HOST as Greg might say BUILD
 221 18:16:32 <sgk_>	Jason_at_intel:  what would be the distnction between "high level" and "low level" ?
 222 18:16:33 <GregNoel>	I won't argue here; I'll push over the proposal; critique at your leisure.
 223 18:16:40 <sgk_>	okay
 224 18:16:48 <sgk_>	just reaching exit for shuttle stop
 225 18:16:57 <sgk_>	< 1 minute
 226 18:17:14 <bdbaddog>	any reason not to start coding as proposed?
 227 18:17:19 <sgk_>	Jason_at_intel:  examples of "high level" vs. "low level" ?
 228 18:17:20 <bdbaddog>	Naming aside ?
 229 18:17:23 <Jason_at_intel>	high level is x86, x86_64... low level is p3, p4, amd64
 230 18:17:28 <sgk_>	and what it provides that the GNU model doesn't already cover?
 231 18:17:31 <garyo-home>	jason: I agree
 232 18:17:49 *	BinkyTheClown (n=binky@unaffiliated/binkytheclown) has joined #scons
 233 18:17:52 <bdbaddog>	I think realisticaly the low level is left for the user to implement at this point.
 234 18:18:03 <garyo-home>	sgk: compiler flags to generate specific code (SSE2, SSE3).  Prob not that important for us.
 235 18:18:07 <bdbaddog>	it's flags on top of whatever flags are set for bit-ness
 236 18:18:15 <garyo-home>	bdbaddog: that's right, for now at least.
 237 18:18:19 <sgk_>	iirc, boost distinguishes between 32-bit and 64-bit "memory model"
 238 18:18:27 <bdbaddog>	yes. not forever, but we have bigger fish to fry
 239 18:18:36 <Jason_at_intel>	I was was just simplifying term to a simple set, as i could not justify to other the need for the other stuff
 240 18:18:36 <sgk_>	okay, shuttle
 241 18:18:41 <sgk_>	good work, folks
 242 18:18:46 <sgk_>	i'll check the log for follow-on discussion
 243 18:18:47 <bdbaddog>	l8r SGK
 244 18:18:50 <garyo-home>	ok, bye for now SGK
 245 18:18:50 *	sgk_ has quit (Read error: 104 (Connection reset by peer))
 246 18:19:33 <bdbaddog>	Anyone have feedback + or - for my proposed reorg?
 247 18:19:56 <Jason_at_intel>	I think the move for get_architecture is correct
 248 18:19:58 <bdbaddog>	mainly focused on win32/visual studio/visual c initially.
 249 18:20:34 <bdbaddog>	I figure sunos/irix/hpux/etc would then handle their possible CPU's
 250 18:21:01 <bdbaddog>	in some sense OS===PLATFORM
 251 18:21:26 <garyo-home>	bdbaddog: seems OK to me.
 252 18:21:34 <GregNoel>	platform==unix, os==ultrix
 253 18:21:47 <bdbaddog>	:) ultrix
 254 18:21:51 <bdbaddog>	ahh memories.
 255 18:22:15 <GregNoel>	OK, os==solaris
 256 18:22:08 <Jason_at_intel>	does this mean we will say linux.. instead of posix?
 257 18:22:59 <GregNoel>	no idea.  you asked for an example.
 258 18:23:13 <garyo-home>	jason: yes, I'd say linux/bsd/irix, not just "unix" for all of them.
 259 18:23:27 <garyo-home>	.. or posix.
 260 18:23:38 <Jason_at_intel>	platform=linux os=RH
 261 18:23:53 <bdbaddog>	re posix; I agree, but not sure how much that might break in userland if we make that change.
 262 18:23:54 <Jason_at_intel>	or platform==os==linux
 263 18:23:58 <bdbaddog>	probably need deprecation cycle?
 264 18:24:04 <GregNoel>	Uh, that's vendor==redhat, os==gnu
 265 18:24:17 <bdbaddog>	os=GNU/Linux
 266 18:24:28 <garyo-home>	I would *not* say os=RH/Ubuntu; that's a distro, the OS is still linux.
 267 18:24:41 <bdbaddog>	anyway it's really semantics at some point.
 268 18:24:48 <GregNoel>	vendor==ubuntu
 269 18:24:55 <garyo-home>	Greg has it right there, vendor=ubuntu.
 270 18:24:56 <bdbaddog>	and none of that really impacts vs_revamp issues.
 271 18:24:58 <Jason_at_intel>	vender makes sence
 272 18:25:10 <garyo-home>	but it's not very relevant to Bill's task right now.
 273 18:25:14 <bdbaddog>	and none of that needs to happen in 1.3
 274 18:25:35 <bdbaddog>	we can add HOST_VENDOR/TARGET_VENDOR in 2.x
 275 18:25:45 <Jason_at_intel>	seem like a good idea
 276 18:25:52 <garyo-home>	sure, if it turns out to actually affect something :-)
 277 18:26:01 <bdbaddog>	and that leaves time to figure out which names we'll use.
 278 18:26:12 <garyo-home>	Actually it could, for packaging.  rpm vs. deb for instance.
 279 18:26:26 <Jason_at_intel>	and kernel drivers
 280 18:26:33 <bdbaddog>	true, but that's sort of user space issues.
 281 18:26:45 <garyo-home>	for sure.
 282 18:27:04 <bdbaddog>	if we add too much user space stuff to scons, we'll never improve it.
 283 18:27:11 <Jason_at_intel>	that is why i have not touched in yet in what i have worked on
 284 18:27:40 <bdbaddog>	and/or maybe in a contrib/unsupported/future package.
 285 18:27:48 <bdbaddog>	sorry module.
 286 18:28:19 <garyo-home>	contrib++
 287 18:28:40 <bdbaddog>	O.k. so I'll start coding all that up (the HOST_OS|CPU, TARGET_OS|CPU) for win32.
 288 18:28:50 <garyo-home>	sounds great to me.
 289 18:28:54 <Jason_at_intel>	so is it _ARCH or _CPU
 290 18:28:59 <bdbaddog>	_CPU
 291 18:29:00 <Jason_at_intel>	i had this from our talk
 292 18:29:06 <Jason_at_intel>	<Jason_at_intel>
 293 18:29:08 <Jason_at_intel>	HOST/TARGET_OS _ARCH or ARCHITECTURE
 294 18:29:10 <Jason_at_intel>	<stevenknight>
 295 18:29:11 <Jason_at_intel>	i thought the consensus was that "platform" should conceptually mean the tuple of relevant things
 296 18:29:13 <Jason_at_intel>	<stevenknight>
 297 18:29:14 <Jason_at_intel>	_OS and _ARCH
 298 18:29:23 <Jason_at_intel>	I missed when this was changed
 299 18:29:43 <bdbaddog>	I think Steven and Greg conversed about this, and sugguested HOST_CPU
 300 18:29:50 <garyo-home>	Bill: I kind of like _ARCH myself for x86/x86_64/mips
 301 18:30:06 <bdbaddog>	I'm agnostic.
 302 18:30:11 <bdbaddog>	about _CPU or _ARCH
 303 18:30:20 <Jason_at_intel>	I was pushing for having CPU and ARCH
 304 18:30:29 <bdbaddog>	well. maybe not.. _ARCH is probably appropriate for this level of specificity
 305 18:30:30 <Jason_at_intel>	ideally add CPU later
 306 18:30:47 <bdbaddog>	Greg U still there?
 307 18:30:58 <garyo-home>	Yes, that's why I like arch.  Leaves room for more specific cpu.
 308 18:31:06 <GregNoel>	sorta; being distracted by pizza
 309 18:31:10 <bdbaddog>	:)
 310 18:31:46 <bdbaddog>	U have an opinion _CPU vs _ARCH when its at the level of x86 and x86_64 vs P4/Core2/Atom/ whatever
 311 18:31:54 <GregNoel>	I favor CPu because we can leverage autoconf stuff; if you deem it must be called arch, then that's not my problem.
 312 18:32:28 <Jason_at_intel>	how do you plan to leverage autoconf?
 313 18:32:40 <Jason_at_intel>	I thought you want to build in a autoconf like system?
 314 18:32:47 <bdbaddog>	we can default CPU = ARCH and then user/platform  can set/user more specific?
 315 18:32:49 <Jason_at_intel>	but not copy everything
 316 18:33:13 <garyo-home>	I think GNU uses ARCH for this, at least sometimes.  See http://pingus77.free.fr/Gentoo/240/files/xdtv-2.4.0-mmx.patch
 317 18:33:17 <garyo-home>	(which I just googled)
 318 18:33:22 <GregNoel>	Just about everybody who configures machines for cross-compiles knows GNU triples; I want people converting from Autoconf to be comfortable.
 319 18:33:30 <Jason_at_intel>	got to love google
 320 18:34:06 <Jason_at_intel>	i guess i never got autoconf to easy work for cross builds
 321 18:34:24 <Jason_at_intel>	it always was to hard to get it to work
 322 18:34:26 <garyo-home>	"OS: linux-gnu, ARCH: i386, CPU: i686" <--- from another google
 323 18:34:27 <BinkyTheClown>	GregNoel: that's me ;)
 324 18:35:01 <bdbaddog>	GregNoel: I'm not that familiar with autoconf, what's their terms?
 325 18:35:25 <garyo-home>	OK BinkyTheClown: would you expect ARCH=x86 and CPU=Core2, or just CPU=x86?
 326 18:35:26 <GregNoel>	garyo-home, but what's the GNU triple?  It'll say x86.
 327 18:35:34 <Jason_at_intel>	I agree that we need at least  OS and ARCH for cross builds.. I don't see the need for vender or a CPU
 328 18:36:01 <Jason_at_intel>	I cross build all the time, but maybe I am missing something
 329 18:36:27 <BinkyTheClown>	garyo-home: I'd expect CPU=Core2
 330 18:36:47 <Jason_at_intel>	the triple can also say intel64 amd64 and x86_64
 331 18:36:54 <BinkyTheClown>	garyo-home: and ARCH=x86
 332 18:37:44 <GregNoel>	No, the triple can only say x86_64.  Anything else is canonicalized.  Try it.
 333 18:37:53 <Jason_at_intel>	so I am for the arch=x86 and cpu=p4r2-see2
 334 18:37:54 <garyo-home>	How do I try it?
 335 18:38:08 <GregNoel>	Look for config-sub.
 336 18:38:36 <GregNoel>	There's probably a copy on your system somewhere; if there's a configure.in, there's a config.sub.
 337 18:40:25 <garyo-home>	my config.sub (Ubuntu 9.04) allows x86, i386, i686, x86_64 at least for cpu
 338 18:40:27 <bdbaddog>	ok. so sounds like HOST_OS, HOST_ARCH (and future HOST_CPU)
 339 18:41:07 <Jason_at_intel>	gary: that is why i like _arch and _CPU
 340 18:41:37 <GregNoel>	try 'config.sub blah-garyo-linux' for blah in x86, i386, i686, x86_64, amd64, ...
 341 18:42:51 <garyo-home>	yup, I did.  It accepts (and returns exactly) those, except for amd64.
 342 18:43:17 <garyo-home>	(which it canonicalizes to x86_64).
 343 18:43:23 <garyo-home>	it's a shell script, btw.
 344 18:43:26 <GregNoel>	Then GNU considers them significantly different, and we should use them.  What more can I say?
 345 18:43:28 <Jason_at_intel>	I think the point we have to remember is why does the user care about these values
 346 18:44:22 <Jason_at_intel>	do 80% of user building care about i386 or i686.. I woudl say no
 347 18:44:33 <Jason_at_intel>	packaging they might care mroe.. but building .. no
 348 18:45:22 <garyo-home>	again, ARCH is high level (x86 vs. x86_64 vs. mips4 vs. powerpc), CPU should be lower level (386 vs 686 vs mmx)
 349 18:45:36 <GregNoel>	garyo-home: don't look in the shell script; it's contaminated with the GNU virus
 350 18:45:54 <garyo-home>	Oh no, I'm infected.
 351 18:46:26 <Jason_at_intel>	GNU virus?
 352 18:46:31 <GregNoel>	I've been very careful not to look inside, in case we have to reverse-engineer it.
 353 18:46:34 <garyo-home>	ah-choo!
 354 18:47:05 <bdbaddog>	o.k. I've gotta check out. But I'll code to HOST_OS, HOST_ARCH (with HOST_CPU to be future)
 355 18:47:08 <Jason_at_intel>	so everyone is saying  HOST_OS, HOST_ARCH (and future HOST_CPU)
 356 18:47:24 <Jason_at_intel>	is this agreeable?
 357 18:47:31 <bdbaddog>	I can also float it to the dev list.
 358 18:47:32 <garyo-home>	I think that will be pretty clear to everyone.
 359 18:47:38 <bdbaddog>	+1
 360 18:47:47 <Jason_at_intel>	+1
 361 18:47:50 <garyo-home>	bdbaddog: sure, mention it why not
 362 18:49:07 <bdbaddog>	O.k. Now to actaully do the work... ;)
 363 18:49:10 <bdbaddog>	Good night to all!
 364 18:49:13 <garyo-home>	Just for kicks, here's what "dpkg-architecture" says about this:
 365 18:49:17 <garyo-home>	garyo@server1:~$ dpkg-architecture
 366 18:49:19 <garyo-home>	DEB_BUILD_ARCH=i386
 367 18:49:21 <garyo-home>	DEB_BUILD_ARCH_OS=linux
 368 18:49:22 <garyo-home>	DEB_BUILD_ARCH_CPU=i386
 369 18:49:23 <garyo-home>	DEB_BUILD_GNU_CPU=i486
 370 18:49:25 <garyo-home>	DEB_BUILD_GNU_SYSTEM=linux-gnu
 371 18:49:26 <garyo-home>	DEB_BUILD_GNU_TYPE=i486-linux-gnu
 372 18:49:28 <garyo-home>	DEB_HOST_ARCH=i386
 373 18:49:29 <garyo-home>	DEB_HOST_ARCH_OS=linux
 374 18:49:31 <garyo-home>	DEB_HOST_ARCH_CPU=i386
 375 18:49:32 <garyo-home>	DEB_HOST_GNU_CPU=i486
 376 18:49:34 <garyo-home>	DEB_HOST_GNU_SYSTEM=linux-gnu
 377 18:49:36 <garyo-home>	DEB_HOST_GNU_TYPE=i486-linux-gnu
 378 18:49:37 <garyo-home>	and now to all a good night.
 379 18:49:45 <GregNoel>	G'day, mate.
 380 18:49:46 <Jason_at_intel>	night!
 381 18:50:02 *	bdbaddog has quit ("ChatZilla 0.9.84 [Firefox 3.0.10/2009042315]")
 382 18:50:05 *	garyo-home has quit ("ChatZilla 0.9.84 [Firefox 3.0.10/2009042316]")
 383 18:50:18 *	Jason_at_intel has quit ("ChatZilla 0.9.84 [Firefox 3.0.7/2009021910]")
 384 18:50:18 *	GregNoel has been marked as being away
 385 

BugParty/IrcLog2009-05-13 (last edited 2009-05-14 05:15:50 by ip68-7-77-81)