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
