IrcLog2009 01 21

16:54:30 * garyo-home (n=chatzill@209-6-158-38.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has joined #scons 16:55:27 * bdbaddog (n=bdeegan@adsl-71-142-75-191.dsl.pltn13.pacbell.net) has joined #scons 17:10:54 * jason_at_intel (n=jason_at@bementil-116.illinois.prairieinet.net) has joined #scons 17:22:51 * stevenknight (n=stevenkn@67.218.106.140) has joined #scons 17:28:44 hello all 17:28:49 Hi guys, I'm here. 17:28:53 Greetings! 17:28:59 Welcome, Bill! 17:29:03 <GregNoel> Hi, all; just got here myself. 17:29:23 <GregNoel> Shall we start? 17:29:39 ready when you are 17:29:40 Sure. I put some quick comments in the spreadsheet, hope that's helpful. 17:29:52 always 17:30:05 * GregNoel has mislaid his glasses... 17:30:30 GregNoel, glasses, P1 17:30:34 :-) 17:31:09 <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 hi jason 17:30:57 1766: consensus 2.x p4 someone 17:31:10 1766: done 17:31:29 <GregNoel> ok, although I'm already worried about getting too much in 2.x 17:31:43 it's p4 though 17:32:00 we've generally said that 2.x will require some sort of re-classification 17:32:20 <GregNoel> Yeah, but how often do we push out an issue? 17:32:38 42 times 17:32:41 :) 17:32:54 <GregNoel> Yeah, that's "the answer" all right 17:32:49 I'm OK w/ 3.x instead if you like. 17:32:55 after that, it's history 17:33:01 i'm okay with 3.x too 17:33:16 <GregNoel> 3.x p2? 17:33:21 works for me 17:33:25 p3, it's still cosmetic. 17:33:53 <GregNoel> OK, done 17:33:54 ? 17:33:57 ok 17:34:10 1766: 3.x p2 done 17:34:20 * Azverkan (n=chatzill@99.52.200.251) has joined #scons 17:34:42 <GregNoel> Hi, Brandon, we've already started 17:34:54 hey Brandon 17:34:55 Hi Brandon! 17:35:01 Wow, full house tonight! 17:35:04 hey 17:34:28 I think 1202 is not that easy. 17:34:30 1202: consensus 2.x p2 TBD? 17:35:31 <GregNoel> 1202: who? 17:35:50 I'm afraid Steven's the only one who understands that. 17:36:01 yeah, probably right 17:36:13 1202: 2.x p2 stevenknight 17:36:16 <GregNoel> done 17:36:23 <jason_at_intel> it is known that chdir does not work with -j option? 17:36:39 That's another wrinkle. 17:36:51 jason_at_intel: yes, it's documented in the man page 17:36:52 <jason_at_intel> ok 17:37:14 Python doesn't have separate chdir per thread 17:37:21 1205: 17:37:28 1205: Steven, your idea is excellent. We get it so much on the mailing list. 17:37:43 Just subst the strings and compare. 17:38:01 I could do that. 17:38:01 <GregNoel> Concur, but subst too often and it's expensive. 17:38:13 Greg: only do it just before printing the error. 17:38:19 only case that breaks down for its env['ENV'] 17:38:28 but this is kind of a corner case anyway, when you have the same target through two construction environments 17:38:40 so it shouldn't be critical path 17:38:35 <GregNoel> Hmmm... Do you have both envs at that point? 17:38:44 yes, you have both 17:38:53 the new one and the one already attached to the target 17:38:55 <GregNoel> OK, I'll buy it, 2.x 17:39:14 1205: 2.x p2 garyo 17:39:17 <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 Jason: yes would be nice, but who'd ever turn it on. :-) 17:39:39 extra credit for a warning option... 17:39:45 <jason_at_intel> Gary.. We would to test why a build failed 17:39:48 ok, we'll see. 17:39:48 gary gets to help clean the erasers 17:40:07 <GregNoel> {;-} 17:40:12 1888: 17:40:16 <GregNoel> 1888: Dependency loops in Java and FORTRAN. 17:40:16 <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> 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> 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> 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> 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> 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 if only we could harness GregNoel's mad typing skillz for a benign purpose... :-) 17:40:58 <jason_at_intel> lol 17:41:10 <GregNoel> practice, practice, practice... 17:41:15 C code has the same as above too 17:41:18 reading... 17:41:21 DLL depends on EXE depends on DLL 17:41:38 Azverkan: yes, but you never have to compile them both together. 17:41:43 <GregNoel> Not the same library, I hope 17:41:46 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 1888. 17:42:21 In Windows, you only need the .lib and that's partly why. 17:42:34 * GregNoel never ceases to be amazed at the perversity of DOS 17:43:02 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 wasn't in VAX/VMS though.. (Mr. Cutler) 17:42:29 GregNoel: do you see a path to it without some heavy rearchitecting? 17:43:27 <GregNoel> I'm not sure. I think we could get there with stepwise refinement. 17:44:17 <GregNoel> It would need some planning, though 17:44:00 Would batch building help, at least some? 17:44:28 <GregNoel> Yes, we're retriaging it because it was blocked by the batch builder issue 17:44:09 Greg has the strongest handle on it, so... 17:44:18 agreed! 17:44:25 1888: GregNoel, 2.x, p4? 17:44:34 3.x? 17:44:38 :-/ 17:44:39 i can go with 3.x 17:44:43 <GregNoel> Ouch! That's what I get; yeah, 3.x 17:45:01 the architect-y pieces make it seem more Greg than David 17:45:19 okay, 1888: GregNoel, 3.x p4 done 17:45:28 <GregNoel> I may create some partial issues that make up the steps; they may need to be done sooner 17:46:44 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> Which note? 17:46:38 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 That's Steven's note (considered assigning it to David) 17:47:04 <GregNoel> Er, that's Steven's note, nominating David 17:47:04 jason_at_intel: that was me (far left column) 17:47:24 <GregNoel> jinx 17:47:22 <jason_at_intel> ahh... my bad 17:47:22 onward? 17:47:24 Anyway, how about 2286? 17:47:54 2286: I'm cool with VisualStudio keyword and putting it in that pot 17:48:06 Brandon, if you have some cycles to consult on things these days... 17:48:11 <GregNoel> Since I have no clue, I'm fine with that. 17:48:08 But is there anything to do really? Brandon? 17:48:15 I've been in the midst of some serious Windows / Visual Studio refactoring 17:48:36 would appreciate being able to reality-check things with you 17:48:45 its up to what we want to support 17:49:06 I personally think precompiled headers are useless and not worth supporting so I'm a bad person to task 17:49:25 <GregNoel> Azverkan, hear, hear 17:49:10 Azverkan: is this an area where there's a clearly "right" way 17:49:19 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 How about closing the bug with a HOWTO that explains the SCons Way? 17:49:35 or is this up to the project and we need to support multiple ways of doing things anyway? 17:49:35 the problem is that precompiled headers are extremely buggy 17:49:49 if you compile with code optimization enabled you'll get mangled assembly alot 17:49:50 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 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> So what's the consensus? 17:51:10 one thing I would definitely not do is enable precompiled headers for visual studio by default 17:51:15 make the user explicitly do it 17:51:27 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 Jason: have to do something. 17:51:45 <jason_at_intel> I mean make the users do it 17:51:47 How about Brandon closes the bug with a comment explaining a better way? 17:52:36 <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 right now i'm leaning towards documenting that you have to do this 17:52:38 adding the .obj to your list explicitly isn't hard 17:52:45 and it makes what's going on obvious 17:52:56 <jason_at_intel> I woudl second the documentation solution 17:52:56 i'd be leary of magically adding the .obj file for someone under the covers 17:53:06 which seems to be the only way to solve this in code 17:52:59 +1 17:53:05 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 if not then I say ok 17:53:21 ok w/ me too 17:53:42 Azverkan: can we put your name on it and you and I sync up on it later? 17:53:48 sure 17:54:14 okay, 2286: 2.x p3 Azverkan 17:54:18 change the component to documentation 17:54:21 <GregNoel> done; make it research to get it off the bug party's plate? 17:54:31 research is good 17:54:49 <GregNoel> I'll do that; next? 17:55:11 2287: 2.x p3 17:55:38 <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 who? 17:55:17 I'll do that. 17:55:37 I have a few RedHat machines I can use. 17:56:05 <GregNoel> OK, garyo, done 17:56:07 okay, 2287: 2.x p3 garyo, feel free to push it out if it's hard 17:56:13 will do. 17:56:11 done 17:56:20 2288: consensus invalid 17:56:34 <GregNoel> done 17:57:01 2289: GregNoel, invalid or wontfix based on info 17:57:26 <GregNoel> 2289: I'd prefer to skip it until next time 17:57:39 okay, if you want to retriage that's fine 17:57:49 <GregNoel> done 17:58:21 2291: 2.x p3, anyone other than me? 17:58:28 2291: isn't ctypes to be preferred over pywin32? 17:58:45 Azverkan? 17:58:49 <GregNoel> Can it be handled by compat? 17:59:00 seems to me like it should be if it's now part of standard Python 17:59:10 That might be even better. 17:59:21 only potentially issue with ctypes is 64 bit python binaries 17:59:37 ? 17:59:44 <jason_at_intel> pywin32 has the same issue does it not? 18:00:02 pywin32 has those issues in the COM code 18:00:07 but not for the win32api stuff 18:00:29 <jason_at_intel> hmm I most have a bad drop then 18:01:28 Jason, do you have a win64 machine w/ 64-bit python? 18:01:37 <jason_at_intel> yep 18:01:47 Maybe you could help Azverkan test this? 18:01:50 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 (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 I think the point is to reduce dependencies where possible. 18:04:09 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 ... 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> Who's winning? {;-} 18:05:38 <jason_at_intel> activestate python has been shipping it as standard for some time 18:05:38 billg 18:06:10 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 I guess pywin32, fallback to ctypes makes sense. 18:06:20 so you could drop pywin32 completely 18:06:45 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 Let's not unless forced to. This isn't the forcing issue. 18:07:47 is ctypes or pywin32 faster? 18:08:00 ctypes is probably 1/10th or less the size of pywin32 18:08:05 hmm... seems like this is a research issue? 18:08:09 All this patch does is set a flag somewhere. 18:08:12 yes research. 18:08:16 Speed's not an issue. 18:08:23 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 http://developer.nvidia.com/object/fx_composer_home.html 18:09:10 Azverkan, can you take it and research? 18:09:16 sure 18:09:23 okay 18:09:31 2291: Azverkan, research 18:09:32 done 18:09:34 <GregNoel> done 18:10:00 2292: 18:10:22 lump it in with the previous PCH issue? 18:10:17 2292 depends on the other stdafx bug I think 18:10:29 what Azverkan said 18:10:45 <GregNoel> link them or dup one? 18:10:59 link, I think. They seem a bit different. 18:11:01 link for now 18:11:08 heads up: my shuttle stop in 5-10 minutes 18:11:32 2293: another PCH 18:11:38 simpler, though 18:11:53 I just hit this one myself today 18:12:06 Greg's basically right 18:12:23 <GregNoel> I think this is from when we separated CCFLAGS out; this tool was never changed. 18:12:23 I don't see a reason not to include $CCFLAGS on the $PCHCOM command line 18:12:38 <GregNoel> what stevenknight said 18:12:40 I believe it. 18:13:04 I'll do it in that case. 18:13:05 <GregNoel> 2.1 p2 garyo? 18:13:13 sure. 18:13:17 <GregNoel> done 18:13:20 could be anytime, actually 18:13:31 I'll try to do it sooner. 18:13:52 <GregNoel> anytime it is 18:14:02 done 18:14:12 2294: Greg, you tried this? 18:14:16 2294: return for more info / reproducible test case? 18:14:28 +1 18:14:40 (esp. OS/compiler) 18:14:54 <GregNoel> yes, but I didn't get any configure messages, and the case succeeded. The log had both messages reported 18:15:07 so worksforme? 18:15:38 <GregNoel> It still gets the unexpected "no result" message; I have no idea where it comes from 18:15:29 when I tried Configure I've run into similar problems with ldconfig problems in the compiler getting hidden 18:15:42 I think the main problem is that its not spammy enough in a log file somewhere 18:16:09 The log file does get everything, I think, but it's not always easy to find. 18:16:24 you can say that again... 18:16:32 <GregNoel> Get more info and try again next time? 18:16:34 I could have sworn I've seen it drop things from children of child processes 18:16:37 anyway, I still like get more info. 18:16:54 Azverkan: could be... 18:17:24 <GregNoel> Brandon, you want to look into it? 18:17:37 last minute for me 18:17:43 I know zero about the configure stuff 18:17:59 <GregNoel> then skip for now; I'll get more info 18:18:02 <GregNoel> last one? 18:18:00 2295 is consensus 2.x p2/p3 18:18:18 <GregNoel> who? 18:18:06 my suggestion: 2295 2.x p3 me or someone else 18:18:06 <GregNoel> done 18:18:19 ok, just in time! 18:18:25 if you guys want to continue with 2005q1 there's a lot of consensus there 18:18:30 could even be pulled out off-line 18:18:52 i'd be totally okay with what you decide 18:18:48 <GregNoel> I can't; going out to dinner in 20 mins 18:18:59 okay 18:19:13 I'll volunteer to input the consensus ones from that spreadsheet 18:19:17 i might take a pass through that spreadsheet on the bus tomorrow then and handle the obvious cases? 18:19:31 <GregNoel> worksforme; mark them in the spreadsheet 18:19:45 okay 18:19:49 i'm gone 18:19:49 Steven, you'll do that then? 18:19:50 * stevenknight has quit ("Leaving") 18:20:12 <GregNoel> (use "join columns" so you can make the message wider) 18:20:22 OK guys, sounds like that's it for tonight, thanks all for showing up! 18:20:36 <GregNoel> Yes, good to see you all! 18:20:36 no problemo 18:20:39 <jason_at_intel> ok latter 18:20:49 <GregNoel> Will we see you all two weeks from now? 18:20:57 <jason_at_intel> yes 18:21:07 Yes, I can do it. 18:21:10 be in taiwan then not sure what time the bugparty lands there :) 18:25:39 * garyo-home has quit ("ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]") 18:26:13 * jason_at_intel has quit (" HydraIRC -> http://www.hydrairc.com <- s0 d4Mn l33t |t'z 5c4rY!") 18:54:59 * bdbaddog has quit ("Leaving.") 21:50:10 * Azverkan (n=chatzill@99.52.200.251) has left #scons