-
-
Notifications
You must be signed in to change notification settings - Fork 319
IrcLog2009 01 21
William Deegan edited this page Jan 14, 2016
·
2 revisions
16:54:30 * garyo-home (n=[[email protected]](mailto:[email protected])) has joined #scons
16:55:27 * bdbaddog (n=[[email protected]](mailto:[email protected])) has joined #scons
17:10:54 * jason_at_intel (n=[[email protected]](mailto:[email protected])) has joined #scons
17:22:51 * stevenknight (n=[[email protected]](mailto:[email protected])) has joined #scons
17:28:44 <stevenknight> hello all
17:28:49 <garyo-home> Hi guys, I'm here.
17:28:53 <bdbaddog> Greetings!
17:28:59 <garyo-home> Welcome, Bill!
17:29:03 <[GregNoel](GregNoel)> Hi, all; just got here myself.
17:29:23 <[GregNoel](GregNoel)> Shall we start?
17:29:39 <stevenknight> ready when you are
17:29:40 <garyo-home> Sure. I put some quick comments in the spreadsheet, hope that's helpful.
17:29:52 <stevenknight> always
17:30:05 * [GregNoel](GregNoel) has mislaid his glasses...
17:30:30 <stevenknight> [GregNoel](GregNoel), glasses, P1
17:30:34 <garyo-home> :-)
17:31:09 <[GregNoel](GregNoel)> Actually, p0, since I can't read the spreadsheet very well without them...
17:30:28 <jason_at_intel> hello all
17:30:41 <stevenknight> hi jason
17:30:57 <garyo-home> 1766: consensus 2.x p4 someone
17:31:10 <stevenknight> 1766: done
17:31:29 <[GregNoel](GregNoel)> ok, although I'm already worried about getting too much in 2.x
17:31:43 <garyo-home> it's p4 though
17:32:00 <stevenknight> we've generally said that 2.x will require some sort of re-classification
17:32:20 <[GregNoel](GregNoel)> Yeah, but how often do we push out an issue?
17:32:38 <stevenknight> 42 times
17:32:41 <bdbaddog> :)
17:32:54 <[GregNoel](GregNoel)> Yeah, that's "the answer" all right
17:32:49 <garyo-home> I'm OK w/ 3.x instead if you like.
17:32:55 <stevenknight> after that, it's history
17:33:01 <stevenknight> i'm okay with 3.x too
17:33:16 <[GregNoel](GregNoel)> 3.x p2?
17:33:21 <stevenknight> works for me
17:33:25 <garyo-home> p3, it's still cosmetic.
17:33:53 <[GregNoel](GregNoel)> OK, done
17:33:54 <garyo-home> ?
17:33:57 <garyo-home> ok
17:34:10 <stevenknight> 1766: 3.x p2 done
17:34:20 * Azverkan (n=[[email protected]](mailto:[email protected])) has joined #scons
17:34:42 <[GregNoel](GregNoel)> Hi, Brandon, we've already started
17:34:54 <stevenknight> hey Brandon
17:34:55 <garyo-home> Hi Brandon!
17:35:01 <garyo-home> Wow, full house tonight!
17:35:04 <Azverkan> hey
17:34:28 <garyo-home> I think 1202 is not that easy.
17:34:30 <stevenknight> 1202: consensus 2.x p2 TBD?
17:35:31 <[GregNoel](GregNoel)> 1202: who?
17:35:50 <garyo-home> I'm afraid Steven's the only one who understands that.
17:36:01 <stevenknight> yeah, probably right
17:36:13 <stevenknight> 1202: 2.x p2 stevenknight
17:36:16 <[GregNoel](GregNoel)> done
17:36:23 <jason_at_intel> it is known that chdir does not work with -j option?
17:36:39 <garyo-home> That's another wrinkle.
17:36:51 <stevenknight> jason_at_intel: yes, it's documented in the man page
17:36:52 <jason_at_intel> ok
17:37:14 <stevenknight> Python doesn't have separate chdir per thread
17:37:21 <stevenknight> 1205:
17:37:28 <garyo-home> 1205: Steven, your idea is excellent. We get it so much on the mailing list.
17:37:43 <garyo-home> Just subst the strings and compare.
17:38:01 <garyo-home> I could do that.
17:38:01 <[GregNoel](GregNoel)> Concur, but subst too often and it's expensive.
17:38:13 <garyo-home> Greg: only do it just before printing the error.
17:38:19 <Azverkan> only case that breaks down for its env['ENV']
17:38:28 <stevenknight> but this is kind of a corner case anyway, when you have the same target through two construction environments
17:38:40 <stevenknight> so it shouldn't be critical path
17:38:35 <[GregNoel](GregNoel)> Hmmm... Do you have both envs at that point?
17:38:44 <stevenknight> yes, you have both
17:38:53 <stevenknight> the new one and the one already attached to the target
17:38:55 <[GregNoel](GregNoel)> OK, I'll buy it, 2.x
17:39:14 <stevenknight> 1205: 2.x p2 garyo
17:39:17 <[GregNoel](GregNoel)> done
17:38:59 <jason_at_intel> I agree.. it woudl be nice to have an option to show it however
17:39:19 <jason_at_intel> In large builds this can help find problems
17:39:24 <garyo-home> Jason: yes would be nice, but who'd ever turn it on. :-)
17:39:39 <stevenknight> extra credit for a warning option...
17:39:45 <jason_at_intel> Gary.. We would to test why a build failed
17:39:48 <garyo-home> ok, we'll see.
17:39:48 <stevenknight> gary gets to help clean the erasers
17:40:07 <[GregNoel](GregNoel)> {;-}
17:40:12 <stevenknight> 1888:
17:40:16 <[GregNoel](GregNoel)> 1888: Dependency loops in Java and FORTRAN.
17:40:16 <[GregNoel](GregNoel)> All it takes is two files: A which uses something in B, and B which uses something in A. This is permitted, legal, and common practice in both languages. The solution in both languages is to compile both files in the same batch.
17:40:16 <[GregNoel](GregNoel)> The simple solution would appear to be to put the files from the implicit scan into the command line (i.e., add them to SOURCES). This works for Java, but FORTRAN can also include files the same way that C does, so either the scanner has to return two lists or you need two scanners (hence, an "additional source scanner").
17:40:16 <[GregNoel](GregNoel)> If you've only got a few files, just putting the additional files in SOURCES is fine. However, if you have a lot of files, you can blow out the command line or the limits of the compiler.
17:40:16 <[GregNoel](GregNoel)> In that case, you need to calculate subsets such that the sources that refer to each other (dependency cycles) are all in the same subset and the subsets form a DAG. Each subset can then be dispatched independently (subject to the usual restrictions).
17:40:16 <[GregNoel](GregNoel)> Fortunately, there are at least three algorithms to calculate these subsets, each with varying pros and cons. We may chose not to worry about too many sources initially, but we'll have to do it eventually.
17:40:16 <[GregNoel](GregNoel)> Depending on how we approach it, this evaluation may generate new nodes that will have to be added to the build DAG. I don't know how to do that (or even if it can be done), but that's probably the nastiest aspect that will have to be overcome.
17:40:46 <stevenknight> if only we could harness [GregNoel](GregNoel)'s mad typing skillz for a benign purpose... :-)
17:40:58 <jason_at_intel> lol
17:41:10 <[GregNoel](GregNoel)> practice, practice, practice...
17:41:15 <Azverkan> C code has the same as above too
17:41:18 <stevenknight> reading...
17:41:21 <Azverkan> DLL depends on EXE depends on DLL
17:41:38 <garyo-home> Azverkan: yes, but you never have to compile them both together.
17:41:43 <[GregNoel](GregNoel)> Not the same library, I hope
17:41:46 <Azverkan> but in that case you have to compile a dummy DLL, then the real EXE then the real DLL
17:42:14 <jason_at_intel> which bug is this?
17:42:30 <garyo-home> 1888.
17:42:21 <garyo-home> In Windows, you only need the .lib and that's partly why.
17:42:34 * [GregNoel](GregNoel) never ceases to be amazed at the perversity of DOS
17:43:02 <bdbaddog> I hear u there. dll != shared library...
17:43:11 <jason_at_intel> don't blame DOS.. it a mainframe thing from IBM
17:43:34 <bdbaddog> wasn't in VAX/VMS though.. (Mr. Cutler)
17:42:29 <stevenknight> [GregNoel](GregNoel): do you see a path to it without some heavy rearchitecting?
17:43:27 <[GregNoel](GregNoel)> I'm not sure. I think we could get there with stepwise refinement.
17:44:17 <[GregNoel](GregNoel)> It would need some planning, though
17:44:00 <garyo-home> Would batch building help, at least some?
17:44:28 <[GregNoel](GregNoel)> Yes, we're retriaging it because it was blocked by the batch builder issue
17:44:09 <stevenknight> Greg has the strongest handle on it, so...
17:44:18 <garyo-home> agreed!
17:44:25 <stevenknight> 1888: [GregNoel](GregNoel), 2.x, p4?
17:44:34 <garyo-home> 3.x?
17:44:38 <garyo-home> :-/
17:44:39 <stevenknight> i can go with 3.x
17:44:43 <[GregNoel](GregNoel)> Ouch! That's what I get; yeah, 3.x
17:45:01 <stevenknight> the architect-y pieces make it seem more Greg than David
17:45:19 <stevenknight> okay, 1888: [GregNoel](GregNoel), 3.x p4 done
17:45:28 <[GregNoel](GregNoel)> I may create some partial issues that make up the steps; they may need to be done sooner
17:46:44 <stevenknight> [GregNoel](GregNoel): ++ to partial steps
17:45:31 <jason_at_intel> I have to agree with Davids note
17:45:43 <jason_at_intel> those cycles are wrong
17:45:54 <[GregNoel](GregNoel)> Which note?
17:46:38 <garyo-home> Jason?
17:46:40 <jason_at_intel> I don't know Dependency cycles just seem wrong to me,...
17:47:04 <jason_at_intel> sure... Just dicovered this GUI does not support copy and paste :-(
17:47:04 <garyo-home> That's Steven's note (considered assigning it to David)
17:47:04 <[GregNoel](GregNoel)> Er, that's Steven's note, nominating David
17:47:04 <stevenknight> jason_at_intel: that was me (far left column)
17:47:24 <[GregNoel](GregNoel)> jinx
17:47:22 <jason_at_intel> ahh... my bad
17:47:22 <stevenknight> onward?
17:47:24 <garyo-home> Anyway, how about 2286?
17:47:54 <stevenknight> 2286: I'm cool with [VisualStudio](VisualStudio) keyword and putting it in that pot
17:48:06 <stevenknight> Brandon, if you have some cycles to consult on things these days...
17:48:11 <[GregNoel](GregNoel)> Since I have no clue, I'm fine with that.
17:48:08 <garyo-home> But is there anything to do really? Brandon?
17:48:15 <stevenknight> I've been in the midst of some serious Windows / Visual Studio refactoring
17:48:36 <stevenknight> would appreciate being able to reality-check things with you
17:48:45 <Azverkan> its up to what we want to support
17:49:06 <Azverkan> I personally think precompiled headers are useless and not worth supporting so I'm a bad person to task
17:49:25 <[GregNoel](GregNoel)> Azverkan, hear, hear
17:49:10 <stevenknight> Azverkan: is this an area where there's a clearly "right" way
17:49:19 <stevenknight> so that we should only support that?
17:49:21 <jason_at_intel> Should i send you my re_vamp work steve?
17:49:22 <garyo-home> How about closing the bug with a HOWTO that explains the SCons Way?
17:49:35 <stevenknight> or is this up to the project and we need to support multiple ways of doing things anyway?
17:49:35 <Azverkan> the problem is that precompiled headers are extremely buggy
17:49:49 <Azverkan> if you compile with code optimization enabled you'll get mangled assembly alot
17:49:50 <garyo-home> Azverkan: agree, I never use PCH even though I do Windows all the time
17:49:33 <jason_at_intel> just a note one this
17:49:45 <jason_at_intel> pre-compiled headers will speed up builds
17:50:00 <jason_at_intel> but they are complex to setup for larger projects
17:50:15 <jason_at_intel> and take a long time to build, compared to just building smarter
17:50:10 <stevenknight> jason_at_intel: sure, let's sync up off-line -- any help is appreciated
17:50:31 <jason_at_intel> OK will sync off line
17:51:01 <[GregNoel](GregNoel)> So what's the consensus?
17:51:10 <Azverkan> one thing I would definitely not do is enable precompiled headers for visual studio by default
17:51:15 <Azverkan> make the user explicitly do it
17:51:27 <Azverkan> as the assembly generation will break for optimized builds in a lot of known cases
17:51:16 <jason_at_intel> I woudl be for just skipping this
17:51:26 <garyo-home> Jason: have to do something.
17:51:45 <jason_at_intel> I mean make the users do it
17:51:47 <garyo-home> How about Brandon closes the bug with a comment explaining a better way?
17:52:36 <[GregNoel](GregNoel)> garyo-home, worksforme; Azverkan, OK with you?
17:51:59 <jason_at_intel> it not easy to setup in VS in the first place
17:52:31 <jason_at_intel> plus it will mess up builds of C++ with templates
17:52:31 <stevenknight> right now i'm leaning towards documenting that you have to do this
17:52:38 <stevenknight> adding the .obj to your list explicitly isn't hard
17:52:45 <stevenknight> and it makes what's going on obvious
17:52:56 <jason_at_intel> I woudl second the documentation solution
17:52:56 <stevenknight> i'd be leary of magically adding the .obj file for someone under the covers
17:53:06 <stevenknight> which seems to be the only way to solve this in code
17:52:59 <bdbaddog> +1
17:53:05 <Azverkan> only thing I would want to double check is that there isn't explicit PCH support in the existing MSVC compiler tool definition
17:53:14 <Azverkan> if not then I say ok
17:53:21 <garyo-home> ok w/ me too
17:53:42 <stevenknight> Azverkan: can we put your name on it and you and I sync up on it later?
17:53:48 <Azverkan> sure
17:54:14 <stevenknight> okay, 2286: 2.x p3 Azverkan
17:54:18 <stevenknight> change the component to documentation
17:54:21 <[GregNoel](GregNoel)> done; make it research to get it off the bug party's plate?
17:54:31 <stevenknight> research is good
17:54:49 <[GregNoel](GregNoel)> I'll do that; next?
17:55:11 <stevenknight> 2287: 2.x p3
17:55:38 <[GregNoel](GregNoel)> 2287, if adding all of the directory is easy (and I think it is), then I'll agree with 2.x p3
17:55:12 <stevenknight> who?
17:55:17 <garyo-home> I'll do that.
17:55:37 <garyo-home> I have a few [RedHat](RedHat) machines I can use.
17:56:05 <[GregNoel](GregNoel)> OK, garyo, done
17:56:07 <stevenknight> okay, 2287: 2.x p3 garyo, feel free to push it out if it's hard
17:56:13 <garyo-home> will do.
17:56:11 <stevenknight> done
17:56:20 <stevenknight> 2288: consensus invalid
17:56:34 <[GregNoel](GregNoel)> done
17:57:01 <stevenknight> 2289: [GregNoel](GregNoel), invalid or wontfix based on info
17:57:26 <[GregNoel](GregNoel)> 2289: I'd prefer to skip it until next time
17:57:39 <stevenknight> okay, if you want to retriage that's fine
17:57:49 <[GregNoel](GregNoel)> done
17:58:21 <stevenknight> 2291: 2.x p3, anyone other than me?
17:58:28 <garyo-home> 2291: isn't ctypes to be preferred over pywin32?
17:58:45 <garyo-home> Azverkan?
17:58:49 <[GregNoel](GregNoel)> Can it be handled by compat?
17:59:00 <stevenknight> seems to me like it should be if it's now part of standard Python
17:59:10 <garyo-home> That might be even better.
17:59:21 <Azverkan> only potentially issue with ctypes is 64 bit python binaries
17:59:37 <garyo-home> ?
17:59:44 <jason_at_intel> pywin32 has the same issue does it not?
18:00:02 <Azverkan> pywin32 has those issues in the COM code
18:00:07 <Azverkan> but not for the win32api stuff
18:00:29 <jason_at_intel> hmm I most have a bad drop then
18:01:28 <garyo-home> Jason, do you have a win64 machine w/ 64-bit python?
18:01:37 <jason_at_intel> yep
18:01:47 <garyo-home> Maybe you could help Azverkan test this?
18:01:50 <Azverkan> I would say make ctypes the default and somebody just fixes ctypes to work if it still doesn't out of the box
18:01:55 <jason_at_intel> I have been tweaking some Parts code for 64-bit python
18:01:59 <Azverkan> (only has 64bit machines now)
18:02:25 <jason_at_intel> the difference is if you run 32-bit python or 64-bit python
18:03:10 <jason_at_intel> I have limited experence with ctypes.. however so far i find pywin32 easier.. but i may not understand ctype well enough yet
18:03:34 <garyo-home> I think the point is to reduce dependencies where possible.
18:04:09 <Azverkan> ctypes is just building up stack memory and jumping to random addresses, it just means that in python you need to manually support every possible calling convention on every architecture instead of letting the compiler do it
18:04:29 <jason_at_intel> so the current solution to use pywin32 then ctypes is good since most people will not have ctypes unless they have a newer python
18:04:59 <garyo-home> ... but then people with newer python *still* need pywin32 (OK, who really *doesn't* need that on Windows?)
18:05:12 * garyo-home is arguing with himself
18:05:27 <[GregNoel](GregNoel)> Who's winning? {;-}
18:05:38 <jason_at_intel> activestate python has been shipping it as standard for some time
18:05:38 <Azverkan> billg
18:06:10 <Azverkan> ctypes does exist for old versions of python, probably back to 2.0
18:06:12 <jason_at_intel> there was another python package that did as well.. forgot the name
18:06:14 <garyo-home> I guess pywin32, fallback to ctypes makes sense.
18:06:20 <Azverkan> so you could drop pywin32 completely
18:06:45 <garyo-home> you mean a user could drop it? yes.
18:06:56 <jason_at_intel> can we have SCOn support python 2.5 or better on windows only?
18:07:54 <jason_at_intel> One thought is that most people on windows will get python 2.6 now
18:08:33 <jason_at_intel> this is not like Linux which ships with python.. you have to install it, so you tend to get the new versions
18:07:25 <garyo-home> Let's not unless forced to. This isn't the forcing issue.
18:07:47 <bdbaddog> is ctypes or pywin32 faster?
18:08:00 <Azverkan> ctypes is probably 1/10th or less the size of pywin32
18:08:05 <stevenknight> hmm... seems like this is a research issue?
18:08:09 <garyo-home> All this patch does is set a flag somewhere.
18:08:12 <bdbaddog> yes research.
18:08:16 <garyo-home> Speed's not an issue.
18:08:23 <Azverkan> jason_at_intel: the problem is that things like FX Composer force you to install python24
18:08:52 <jason_at_intel> FX Composer?
18:09:05 <Azverkan> [http://developer.nvidia.com/object/fx_composer_home.html](http://developer.nvidia.com/object/fx_composer_home.html)
18:09:10 <garyo-home> Azverkan, can you take it and research?
18:09:16 <Azverkan> sure
18:09:23 <stevenknight> okay
18:09:31 <stevenknight> 2291: Azverkan, research
18:09:32 <stevenknight> done
18:09:34 <[GregNoel](GregNoel)> done
18:10:00 <stevenknight> 2292:
18:10:22 <stevenknight> lump it in with the previous PCH issue?
18:10:17 <Azverkan> 2292 depends on the other stdafx bug I think
18:10:29 <stevenknight> what Azverkan said
18:10:45 <[GregNoel](GregNoel)> link them or dup one?
18:10:59 <garyo-home> link, I think. They seem a bit different.
18:11:01 <Azverkan> link for now
18:11:08 <stevenknight> heads up: my shuttle stop in 5-10 minutes
18:11:32 <garyo-home> 2293: another PCH
18:11:38 <stevenknight> simpler, though
18:11:53 <stevenknight> I just hit this one myself today
18:12:06 <stevenknight> Greg's basically right
18:12:23 <[GregNoel](GregNoel)> I think this is from when we separated CCFLAGS out; this tool was never changed.
18:12:23 <stevenknight> I don't see a reason not to include $CCFLAGS on the $PCHCOM command line
18:12:38 <[GregNoel](GregNoel)> what stevenknight said
18:12:40 <garyo-home> I believe it.
18:13:04 <garyo-home> I'll do it in that case.
18:13:05 <[GregNoel](GregNoel)> 2.1 p2 garyo?
18:13:13 <garyo-home> sure.
18:13:17 <[GregNoel](GregNoel)> done
18:13:20 <stevenknight> could be anytime, actually
18:13:31 <garyo-home> I'll try to do it sooner.
18:13:52 <[GregNoel](GregNoel)> anytime it is
18:14:02 <stevenknight> done
18:14:12 <garyo-home> 2294: Greg, you tried this?
18:14:16 <stevenknight> 2294: return for more info / reproducible test case?
18:14:28 <garyo-home> +1
18:14:40 <garyo-home> (esp. OS/compiler)
18:14:54 <[GregNoel](GregNoel)> yes, but I didn't get any configure messages, and the case succeeded. The log had both messages reported
18:15:07 <stevenknight> so worksforme?
18:15:38 <[GregNoel](GregNoel)> It still gets the unexpected "no result" message; I have no idea where it comes from
18:15:29 <Azverkan> when I tried Configure I've run into similar problems with ldconfig problems in the compiler getting hidden
18:15:42 <Azverkan> I think the main problem is that its not spammy enough in a log file somewhere
18:16:09 <garyo-home> The log file does get everything, I think, but it's not always easy to find.
18:16:24 <stevenknight> you can say that again...
18:16:32 <[GregNoel](GregNoel)> Get more info and try again next time?
18:16:34 <Azverkan> I could have sworn I've seen it drop things from children of child processes
18:16:37 <garyo-home> anyway, I still like get more info.
18:16:54 <garyo-home> Azverkan: could be...
18:17:24 <[GregNoel](GregNoel)> Brandon, you want to look into it?
18:17:37 <stevenknight> last minute for me
18:17:43 <Azverkan> I know zero about the configure stuff
18:17:59 <[GregNoel](GregNoel)> then skip for now; I'll get more info
18:18:02 <[GregNoel](GregNoel)> last one?
18:18:00 <garyo-home> 2295 is consensus 2.x p2/p3
18:18:18 <[GregNoel](GregNoel)> who?
18:18:06 <stevenknight> my suggestion: 2295 2.x p3 me or someone else
18:18:06 <[GregNoel](GregNoel)> done
18:18:19 <garyo-home> ok, just in time!
18:18:25 <stevenknight> if you guys want to continue with 2005q1 there's a lot of consensus there
18:18:30 <stevenknight> could even be pulled out off-line
18:18:52 <stevenknight> i'd be totally okay with what you decide
18:18:48 <[GregNoel](GregNoel)> I can't; going out to dinner in 20 mins
18:18:59 <stevenknight> okay
18:19:13 <garyo-home> I'll volunteer to input the consensus ones from that spreadsheet
18:19:17 <stevenknight> i might take a pass through that spreadsheet on the bus tomorrow then and handle the obvious cases?
18:19:31 <[GregNoel](GregNoel)> worksforme; mark them in the spreadsheet
18:19:45 <stevenknight> okay
18:19:49 <stevenknight> i'm gone
18:19:49 <garyo-home> Steven, you'll do that then?
18:19:50 * stevenknight has quit ("Leaving")
18:20:12 <[GregNoel](GregNoel)> (use "join columns" so you can make the message wider)
18:20:22 <garyo-home> OK guys, sounds like that's it for tonight, thanks all for showing up!
18:20:36 <[GregNoel](GregNoel)> Yes, good to see you all!
18:20:36 <bdbaddog> no problemo
18:20:39 <jason_at_intel> ok latter
18:20:49 <[GregNoel](GregNoel)> Will we see you all two weeks from now?
18:20:57 <jason_at_intel> yes
18:21:07 <garyo-home> Yes, I can do it.
18:21:10 <Azverkan> be in taiwan then not sure what time the bugparty lands there :)
18:25:39 * garyo-home has quit ("[ChatZilla](ChatZilla) 0.9.84 [Firefox 3.0.5/2008120122]")
18:26:13 * jason_at_intel has quit (" HydraIRC -> [http://www.hydrairc.com](http://www.hydrairc.com) <- s0 d4Mn l33t |t'z 5c4rY!")
18:54:59 * bdbaddog has quit ("Leaving.")
21:50:10 * Azverkan (n=[[email protected]](mailto:[email protected])) has left #scons