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
