IrcLog2010 08 24

16:43:36 * jason_at_intel (chatzilla@220.sub-75-207-216.myvzw.com) has joined #SCONS 16:54:35 * garyo (garyo@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has joined #SCONS 17:02:56 * sgk (sgk@nat/google/x-zskmujhtignuxavr) has joined #SCONS 17:03:07 hello, who's here? 17:03:11 Hi Steven 17:03:13 <jason_at_intel> Hi Steve! 17:03:55 hi guys 17:04:03 * sgk struggles with getting his windows arranged properly 17:04:42 * garyo is on a tiny screen laptop, everything's maximized all the time 17:04:20 whew! okay 17:04:42 GregNoel here? 17:05:03 Haven't heard from him yet 17:05:27 no bdbaddog either 17:09:22 <GregNoel> I'm here, but I can't stay long... 17:09:32 Hi Greg -- let's get going then. 17:09:52 let's get going then, fortunately not too many bugs tonight 17:09:52 Let's start w/ 2674 I think 17:10:26 2674: defer to next time to see if the OP comes up with anything? 17:10:38 <GregNoel> yes, 2674... seems like consensus to defer 17:10:34 agreed. 17:10:44 <GregNoel> done 17:10:53 <GregNoel> 2675 17:11:01 2675 is either bill or me I think 17:11:15 I think Bill was talking to this guy on the list 17:11:28 yeah, i'd say bdbaddog unless you're really itching to tackle it 17:11:39 not at the moment :-/ 17:11:45 fair enough :-) 17:11:51 <GregNoel> priority and milestone? 17:11:55 research bdbaddog? 17:12:17 or just 2.1 p3, I think msvc issues are important 17:11:57 <jason_at_intel> I don't think that it should be done 17:12:24 jason, huh? 17:12:34 jason_at_intel: why not? 17:12:34 (oh, the fallback) 17:12:42 <jason_at_intel> Ya fallback 17:12:42 garyo: why not? 17:12:53 <jason_at_intel> if you say 64-bit build that .. not 32-bit 17:13:19 <jason_at_intel> fallback is dangerous 17:13:31 <jason_at_intel> people will get stuff they don't expect 17:13:34 is this config explicitly saying 64-bit? I thought the situation was that it was using a default 17:13:33 I think it should be done. He's not specifying anything; scons should make a working exe with whatever compiler you have. 17:13:41 what garyo said 17:13:50 agree that if you explicitly configure 64-bit it should fail 17:13:55 yes 17:14:05 <jason_at_intel> sure.. that is not so bad.. still has risk. 17:14:27 <jason_at_intel> but i will not push it :-) 17:14:32 sure, but people who care about that risk have an easy way to do so: configure the TARGET_ARCH 17:14:26 so bdbaddog 2.1 p3? 17:14:36 bdbaddog 2.1 p3 17:14:50 <GregNoel> done 17:15:04 <GregNoel> 2676 17:15:26 I submitted that just to record it. 3.x is fine w/ me. 17:15:30 <jason_at_intel> is this about the CPPDEFINES setup option? 17:15:35 3.x sounds good 17:15:45 <jason_at_intel> agreed 17:15:59 Basically yes, Jason -- CPPDEFINES is fixed, but there are other theoretical cases. 17:16:58 <jason_at_intel> right.. just checking my understanding 17:16:06 ok 17:16:25 3.x p4, don't need to fill in a name now? 17:16:41 sgk: agree w/ 3.x p4 no name. 17:16:56 <GregNoel> garyo, what other than CPPDEFINES? Remember, CPPDEFINES must also generate -DFOO=bar, so it's not necessarily typical. 17:17:35 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. 17:17:55 <GregNoel> Ah, in that case I'm fine with 3.x p4 17:18:09 <jason_at_intel> I was thinking CPPFLAGS or LINK flags often have var=val 17:18:41 But I don't think we handle dicts in either case there. 17:18:56 <jason_at_intel> true 17:18:41 <jason_at_intel> plus you could use it to help deal with linking static vs dynamic on unix 17:19:08 yes, Bstatic/dynamic could be useful. But changing it when we get there will not be hard. 17:18:39 let's do 3.x p4, we can move it to research when we re-prioritize those 17:16:26 2677 research sk? 17:19:56 any dissent from research p2 sk? 17:20:04 nope 17:20:07 <jason_at_intel> not here 17:20:13 <GregNoel> none, although I think allowing variant dirs to be under src dirs to be dangerous 17:21:02 That would be a bit ... unusual. 17:21:39 <GregNoel> Note that there's one anomoloy (sp) in the treatment already; we don't need to make it worse. 17:21:44 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 17:21:20 <jason_at_intel> I was under the view this was about having these values not under the SConstruct directory 17:21:40 Jason: I think that's what it is about. Build dir entirely elsewhere. 17:22:29 <GregNoel> Build dir outside top dir works fine; I use it all the time. 17:22:55 <GregNoel> but you must specify the directory; it's not built by default. 17:22:24 <jason_at_intel> it can be done... it just that relative paths don't work as expected here 17:22:29 <jason_at_intel> abs paths do 17:23:13 <GregNoel> If that's his problem, the bug is INVALID 17:23:14 (almost shuttle time) 17:23:28 GregNoel: good point 17:23:42 <jason_at_intel> clarification needed? 17:24:01 <GregNoel> needs more info, so ask OP and defer? 17:24:16 <jason_at_intel> +1 17:24:22 okay by me 17:24:32 biab 17:24:34 * sgk has quit (Quit: sgk) 17:24:55 <GregNoel> 2278 17:25:15 * GregNoel is just looking at this for the first time; give me a minute to research 17:25:16 Defer a week to see if OP replies. 17:26:37 * sgk (sgk@nat/google/x-vcwojyshrkoeayvj) has joined #SCONS 17:26:48 Looks like some path needs to be canonicalized to remove ".." to me 17:26:56 Hi Steven, just on 2278 17:27:01 <GregNoel> garyo, agree defer 17:27:51 <jason_at_intel> +1 defer and see if OP replies 17:28:21 <GregNoel> done 17:28:37 OK, skip 2249 since it's bdbaddog's and he's not here? 17:28:38 <GregNoel> 2249, no comments, so looks like defer again? 17:29:00 yes 17:29:14 2485 I think I understand now. 17:29:43 * sgk_ (sgk@67.218.104.161) has joined #SCONS 17:29:53 Configure() is updating the library node's signature, which makes it seem up to date. 17:29:54 * sgk has quit (Disconnected by services) 17:29:57 * sgk_ is now known as sgk 17:30:21 okay, i think i'm back 17:30:21 I suspect 2485 will be hard to fix. 17:30:26 Hi again 17:30:40 <jason_at_intel> do you know what is going on? 17:30:48 Steven, I'd appreciate it if you'd take a look at 2485 some time. 17:30:48 <GregNoel> Hmmm... Side effect from BSR? 17:30:54 What's BSR? 17:31:03 (wait, I know) 17:31:19 No, I think it's just a long-standing SConf bug. 17:31:31 CheckLibrary() actually builds a test program and links it to that lib... 17:31:46 which means the lib gets a Node and it gets updated when the test prog is built. 17:32:06 Then the main world gets the wrong (updated) sig from the lib 17:32:05 <GregNoel> ah 17:31:33 garyo: put my name on it so it stays on the radar screen 17:32:42 OK, I'll add your name. Anyway I think it's out of research mode now, we should assign it a milestone/pri. 17:32:52 I'm thinking 2.x p3 17:33:13 <GregNoel> worksforme 17:33:25 <jason_at_intel> +1 17:33:36 yeah, throw it my way, 2.x p3 sounds good 17:33:41 <GregNoel> done 17:33:52 <GregNoel> 2521 17:34:18 <GregNoel> no comments; defer again? 17:34:19 skip again til bdbaddog is here 17:34:41 2575 17:35:06 <jason_at_intel> I showed Steven the code i had 17:35:20 <jason_at_intel> I think i have an AR to write up something 17:35:27 <jason_at_intel> for discussion 17:35:44 Sounds good -- we did decide on an API, right? 17:36:25 Seemed clever to me at the time I remember. 17:36:27 <GregNoel> tuple(archive-name,real-name) as I recall. 17:36:41 yes 17:37:13 <jason_at_intel> I was not sure we agreed on that 17:37:14 <jason_at_intel> but that was the idea greg pushed 17:37:37 After he showed me how it solved all my cases I was convinced. 17:37:48 ... but that's just me. 17:37:47 <jason_at_intel> not sure how that would work with the current builders sources 17:38:03 It can't be a regular builder. 17:38:28 (e.g. arg2nodes wouldn't work on those tuples) 17:38:32 <GregNoel> I see that as a distinction without a difference ...but that's just me {;-} 17:38:48 Steven: what do you think? 17:39:11 <GregNoel> garyo, actually, I think it does... arg2nodes just ignores them 17:39:28 hmm, cool 17:39:03 <jason_at_intel> Well i guess we want the zip like builder to be callable more than once 17:39:29 i'm honestly not sure, tuples sound attractive from a flexibility standpoint 17:39:41 but i haven't looked at this in any detail 17:40:04 <jason_at_intel> I ok with the idea 17:40:17 <jason_at_intel> I would then want to apply it to the copy builders 17:40:41 <jason_at_intel> ie copy(Dir,[(as this,from this)] 17:40:29 Good idea 17:40:48 yup 17:41:02 is the simple case still simple when using tuples? 17:41:15 i.e. it doesn't require something like specifying all of the files individually 17:41:19 Tuples are optional. Regular node list still works. 17:41:30 And dirs work either as nodes or in tuples. 17:41:49 i.e. Zip(zipfile, [(todir, fromdir)] 17:41:45 <jason_at_intel> do we have a prototype builder doing this? 17:41:59 <jason_at_intel> I though Greg said he had sometime 17:42:12 <GregNoel> I'm being called away; have to leave in a couple of minutes 17:42:13 <jason_at_intel> I would like to see it myself, to use it as a template 17:42:23 Greg said he had something working? 17:42:25 <GregNoel> Yes, I have code 17:42:36 <GregNoel> How should I make it available? 17:42:39 <jason_at_intel> can you share :-) 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) 17:43:20 just email it? 17:43:31 or wiki page? 17:43:34 <GregNoel> works; got to go 17:43:40 ok, c u later 17:43:45 <jason_at_intel> latter greg! 17:43:49 <GregNoel> I'll leave my session open and read the rest later. Bye, all. 17:43:58 ok, I think we're mostly done though 17:44:09 later 17:44:28 <jason_at_intel> cool.. so defer 2575 till Gregs sample can be reviewed? 17:44:41 yeah, we really don't have any more in the spreadsheet 17:44:53 Jason: I agree w/ that. 17:45:07 Then we'll turn it into a regular ticket to implement it. 17:45:24 yeah, that sounds good 17:45:24 any other issues to discuss? 17:45:28 <jason_at_intel> I will apply to some stuff in Parts as well, once i get the feel for it 17:45:37 I'm going to sign off if there's nothing else. 17:45:51 bye 4 now 17:45:54 <jason_at_intel> not at the moment 17:45:55 * garyo (garyo@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has left #SCONS 17:47:39 <jason_at_intel> till next time 17:47:43 later 17:47:46 * sgk (~sgk@67.218.104.161) has left #SCONS 17:47:46 <jason_at_intel> cool 17:48:05 * jason_at_intel has quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.6/20100625231939])