-
-
Notifications
You must be signed in to change notification settings - Fork 319
IrcLog2010 08 24
William Deegan edited this page Jan 14, 2016
·
2 revisions
16:43:36 * jason_at_intel (~[[email protected]](mailto:[email protected])) has joined #SCONS
16:54:35 * garyo (~[[email protected]](mailto:[email protected])) has joined #SCONS
17:02:56 * sgk (~sgk@nat/google/x-zskmujhtignuxavr) has joined #SCONS
17:03:07 <sgk> hello, who's here?
17:03:11 <garyo> Hi Steven
17:03:13 <jason_at_intel> Hi Steve!
17:03:55 <sgk> 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 <sgk> whew! okay
17:04:42 <sgk> [GregNoel](GregNoel) here?
17:05:03 <garyo> Haven't heard from him yet
17:05:27 <sgk> no bdbaddog either
17:09:22 <[GregNoel](GregNoel)> I'm here, but I can't stay long...
17:09:32 <garyo> Hi Greg -- let's get going then.
17:09:52 <sgk> let's get going then, fortunately not too many bugs tonight
17:09:52 <garyo> Let's start w/ 2674 I think
17:10:26 <sgk> 2674: defer to next time to see if the OP comes up with anything?
17:10:38 <[GregNoel](GregNoel)> yes, 2674... seems like consensus to defer
17:10:34 <garyo> agreed.
17:10:44 <[GregNoel](GregNoel)> done
17:10:53 <[GregNoel](GregNoel)> 2675
17:11:01 <garyo> 2675 is either bill or me I think
17:11:15 <garyo> I think Bill was talking to this guy on the list
17:11:28 <sgk> yeah, i'd say bdbaddog unless you're really itching to tackle it
17:11:39 <garyo> not at the moment :-/
17:11:45 <sgk> fair enough :-)
17:11:51 <[GregNoel](GregNoel)> priority and milestone?
17:11:55 <sgk> research bdbaddog?
17:12:17 <garyo> 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 <garyo> jason, huh?
17:12:34 <sgk> jason_at_intel: why not?
17:12:34 <garyo> (oh, the fallback)
17:12:42 <jason_at_intel> Ya fallback
17:12:42 <sgk> 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 <sgk> is this config explicitly saying 64-bit? I thought the situation was that it was using a default
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.
17:13:41 <sgk> what garyo said
17:13:50 <sgk> agree that if you explicitly configure 64-bit it should fail
17:13:55 <garyo> 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 <sgk> sure, but people who care about that risk have an easy way to do so: configure the TARGET_ARCH
17:14:26 <garyo> so bdbaddog 2.1 p3?
17:14:36 <sgk> bdbaddog 2.1 p3
17:14:50 <[GregNoel](GregNoel)> done
17:15:04 <[GregNoel](GregNoel)> 2676
17:15:26 <garyo> 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 <sgk> 3.x sounds good
17:15:45 <jason_at_intel> agreed
17:15:59 <garyo> 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 <garyo> ok
17:16:25 <sgk> 3.x p4, don't need to fill in a name now?
17:16:41 <garyo> sgk: agree w/ 3.x p4 no name.
17:16:56 <[GregNoel](GregNoel)> garyo, what other than CPPDEFINES? Remember, CPPDEFINES must also generate -DFOO=bar, so it's not necessarily typical.
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.
17:17:55 <[GregNoel](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 <garyo> 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 <garyo> yes, Bstatic/dynamic could be useful. But changing it when we get there will not be hard.
17:18:39 <sgk> let's do 3.x p4, we can move it to research when we re-prioritize those
17:16:26 <garyo> 2677 research sk?
17:19:56 <sgk> any dissent from research p2 sk?
17:20:04 <garyo> nope
17:20:07 <jason_at_intel> not here
17:20:13 <[GregNoel](GregNoel)> none, although I think allowing variant dirs to be under src dirs to be dangerous
17:21:02 <garyo> That would be a bit ... unusual.
17:21:39 <[GregNoel](GregNoel)> Note that there's one anomoloy (sp) in the treatment already; we don't need to make it worse.
17:21:44 <sgk> [GregNoel](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 <garyo> Jason: I think that's what it is about. Build dir entirely elsewhere.
17:22:29 <[GregNoel](GregNoel)> Build dir outside top dir works fine; I use it all the time.
17:22:55 <[GregNoel](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](GregNoel)> If that's his problem, the bug is INVALID
17:23:14 <sgk> (almost shuttle time)
17:23:28 <sgk> [GregNoel](GregNoel): good point
17:23:42 <jason_at_intel> clarification needed?
17:24:01 <[GregNoel](GregNoel)> needs more info, so ask OP and defer?
17:24:16 <jason_at_intel> +1
17:24:22 <sgk> okay by me
17:24:32 <sgk> biab
17:24:34 * sgk has quit (Quit: sgk)
17:24:55 <[GregNoel](GregNoel)> 2278
17:25:15 * [GregNoel](GregNoel) is just looking at this for the first time; give me a minute to research
17:25:16 <garyo> Defer a week to see if OP replies.
17:26:37 * sgk (~sgk@nat/google/x-vcwojyshrkoeayvj) has joined #SCONS
17:26:48 <garyo> Looks like some path needs to be canonicalized to remove ".." to me
17:26:56 <garyo> Hi Steven, just on 2278
17:27:01 <[GregNoel](GregNoel)> garyo, agree defer
17:27:51 <jason_at_intel> +1 defer and see if OP replies
17:28:21 <[GregNoel](GregNoel)> done
17:28:37 <garyo> OK, skip 2249 since it's bdbaddog's and he's not here?
17:28:38 <[GregNoel](GregNoel)> 2249, no comments, so looks like defer again?
17:29:00 <garyo> yes
17:29:14 <garyo> 2485 I think I understand now.
17:29:43 * sgk_ (~[[email protected]](mailto:[email protected])) has joined #SCONS
17:29:53 <garyo> 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 <sgk> okay, i think i'm back
17:30:21 <garyo> I suspect 2485 will be hard to fix.
17:30:26 <garyo> Hi again
17:30:40 <jason_at_intel> do you know what is going on?
17:30:48 <garyo> Steven, I'd appreciate it if you'd take a look at 2485 some time.
17:30:48 <[GregNoel](GregNoel)> Hmmm... Side effect from BSR?
17:30:54 <garyo> What's BSR?
17:31:03 <garyo> (wait, I know)
17:31:19 <garyo> No, I think it's just a long-standing SConf bug.
17:31:31 <garyo> [CheckLibrary](CheckLibrary)() actually builds a test program and links it to that lib...
17:31:46 <garyo> which means the lib gets a Node and it gets updated when the test prog is built.
17:32:06 <garyo> Then the main world gets the wrong (updated) sig from the lib
17:32:05 <[GregNoel](GregNoel)> ah
17:31:33 <sgk> garyo: put my name on it so it stays on the radar screen
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.
17:32:52 <garyo> I'm thinking 2.x p3
17:33:13 <[GregNoel](GregNoel)> worksforme
17:33:25 <jason_at_intel> +1
17:33:36 <sgk> yeah, throw it my way, 2.x p3 sounds good
17:33:41 <[GregNoel](GregNoel)> done
17:33:52 <[GregNoel](GregNoel)> 2521
17:34:18 <[GregNoel](GregNoel)> no comments; defer again?
17:34:19 <garyo> skip again til bdbaddog is here
17:34:41 <garyo> 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 <garyo> Sounds good -- we did decide on an API, right?
17:36:25 <garyo> Seemed clever to me at the time I remember.
17:36:27 <[GregNoel](GregNoel)> tuple(archive-name,real-name) as I recall.
17:36:41 <garyo> 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 <garyo> After he showed me how it solved all my cases I was convinced.
17:37:48 <garyo> ... 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 <garyo> It can't be a regular builder.
17:38:28 <garyo> (e.g. arg2nodes wouldn't work on those tuples)
17:38:32 <[GregNoel](GregNoel)> I see that as a distinction without a difference ...but that's just me {;-}
17:38:48 <garyo> Steven: what do you think?
17:39:11 <[GregNoel](GregNoel)> garyo, actually, I think it does... arg2nodes just ignores them
17:39:28 <garyo> 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 <sgk> i'm honestly not sure, tuples sound attractive from a flexibility standpoint
17:39:41 <sgk> 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 <garyo> Good idea
17:40:48 <garyo> yup
17:41:02 <sgk> is the simple case still simple when using tuples?
17:41:15 <sgk> i.e. it doesn't require something like specifying all of the files individually
17:41:19 <garyo> Tuples are optional. Regular node list still works.
17:41:30 <garyo> And dirs work either as nodes or in tuples.
17:41:49 <garyo> 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](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 <garyo> Greg said he had something working?
17:42:25 <[GregNoel](GregNoel)> Yes, I have code
17:42:36 <[GregNoel](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 <garyo> just email it?
17:43:31 <garyo> or wiki page?
17:43:34 <[GregNoel](GregNoel)> works; got to go
17:43:40 <garyo> ok, c u later
17:43:45 <jason_at_intel> latter greg!
17:43:49 <[GregNoel](GregNoel)> I'll leave my session open and read the rest later. Bye, all.
17:43:58 <garyo> ok, I think we're mostly done though
17:44:09 <sgk> later
17:44:28 <jason_at_intel> cool.. so defer 2575 till Gregs sample can be reviewed?
17:44:41 <sgk> yeah, we really don't have any more in the spreadsheet
17:44:53 <garyo> Jason: I agree w/ that.
17:45:07 <garyo> Then we'll turn it into a regular ticket to implement it.
17:45:24 <sgk> yeah, that sounds good
17:45:24 <sgk> 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 <garyo> I'm going to sign off if there's nothing else.
17:45:51 <garyo> bye 4 now
17:45:54 <jason_at_intel> not at the moment
17:45:55 * garyo (~[[email protected]](mailto:[email protected])) has left #SCONS
17:47:39 <jason_at_intel> till next time
17:47:43 <sgk> later
17:47:46 * sgk (~[[email protected]](mailto:[email protected])) has left #SCONS
17:47:46 <jason_at_intel> cool
17:48:05 * jason_at_intel has quit (Quit: [ChatZilla](ChatZilla) 0.9.86 [Firefox 3.6.6/20100625231939])