17:00:52 GregoryNoel It's time. Who's where for the bug party?
17:01:24 * garyo-home (n=chatzill@209-6-158-38.c3-0.smr-ubr3.sbo-smr.ma.cable.rcn.com) has joined #scons
17:01:47 garyo-home Hi folks.
17:01:57 GregoryNoel Folk, singular.
17:02:17 garyo-home Hi, Greg.
17:02:39 GregoryNoel Hi... Nobody here but me and thee.
17:02:52 garyo-home ok, let's wait a bit then.
17:03:05 GregoryNoel yup
17:03:28 GregoryNoel I notice you haven't marked up the current issues. Nothing to say?
17:03:43 garyo-home I assume Steven's on his way, he did the spreadsheet etc.
17:04:20 garyo-home re: current issues: no, I missed them :-(, did all the old ones.
17:04:46 GregoryNoel yes, he did, but basically only he and I marked them up.
17:05:15 garyo-home I did a bunch of old ones actually.
17:05:20 * GregoryNoel overrun by puppy, hang on
17:05:34 garyo-home Grr, current spreadsheet isn't letting me in yet...
17:06:14 * garyo-home has quit (Client Quit)
17:07:10 * garyo-home (n=chatzill@209-6-158-38.c3-0.smr-ubr3.sbo-smr.ma.cable.rcn.com) has joined #scons
17:07:13 * david__ (n=david@mail.ar.media.kyoto-u.ac.jp) has joined #scons
17:07:37 GregoryNoel Ho, David; welcome back, Gary
17:07:44 garyo-home Hi again guys.
17:08:00 garyo-home I still can't write the current issue spreadsheet but I guess it's too late anyway :-(
17:08:10 david__ hello everyone
17:08:34 GregoryNoel It worked fine for me; why do you keep having problems?
17:08:19 david__ Am i late ?
17:08:39 garyo-home no, we're waiting to see who else shows up, hopefully Steven.
17:08:55 garyo-home Greg: bad behavior in previous life perhaps?
17:09:13 GregoryNoel Must be. Or maybe you're overthinking it.
17:09:10 garyo-home Maybe Firefox issue?
17:09:30 GregoryNoel Not Firefox; works for me.
17:09:33 garyo-home Some of them work no prob, others dont.
17:09:44 garyo-home Individual invites have always worked.
17:10:02 david__ does anyone else have slowness problems with spreadsheet ? They are not usable for me, keeps taking 100 %. I have to use another computer for it :)
17:10:19 garyo-home No, they're usually fine foe me.
17:10:19 GregoryNoel They're not fast, but one copes.
17:10:53 GregoryNoel david__, do you use Firefox?
17:10:58 david__ Yes
17:11:13 GregoryNoel 2.0.0.whatever?
17:11:23 david__ firefox 2. something. Other people had problems with it on ubuntu
17:11:34 david__ With spreadsheet, I mean.
17:11:53 GregoryNoel Hmmm... Works fine on my Mac.
17:12:14 garyo-home I'm using ffox 2.0 on win xp. I'll try Ubuntu sometime.
17:12:16 GregoryNoel Maybe you should get yourself a new computer {;-}
17:12:28 GregoryNoel Both of you...
17:12:30 david__ It's a bi-cpu, pentium 4
17:12:32 garyo-home ... or a new OS
17:12:54 garyo-home my hw is fine, fast core 2 duo, 2gb etc.
17:13:01 david__ While p4 are not great, they should make possible to read spreadsheet which look simpler than the ones on excel 95
17:13:41 garyo-home david__, you're right.
17:13:46 GregoryNoel Humpf. PPC 1Ghz rules.
17:13:43 david__ I think there is a bad interaction between ubuntu themes, my hardware and firefox.
17:14:30 david__ So how does this work ? I've just commented on the things I thought I knew something about in the current issues spreadsheet
17:15:16 GregoryNoel We work through the issues and decide where they should go (which milestone and priority)
17:15:54 david__ Which spreadsheets are used, besides the current issues one ?
17:16:10 GregoryNoel The next one not ticked off
17:16:12 garyo-home HA - I can open the spreadsheet just fine (r/w) on Ubuntu Hardy in a VM.
17:16:26 GregoryNoel with luck, the one after that
17:16:36 GregoryNoel and maybe the one after that.
17:16:59 garyo-home OK, maybe Steven's not coming?
17:17:01 david__ @gary: yes, that's the strange thing, it works better in vm on my another computer
17:17:22 garyo-home Should we just start and see what we can do?
17:17:30 GregoryNoel I'm ready
17:17:43 GregoryNoel 1643?
17:17:58 GregoryNoel Has anyone been in contact with Brandon?
17:18:03 garyo-home not me.
17:18:27 garyo-home pass back to OP for more info?
17:18:45 GregoryNoel I'm really hesitant to pass over this again, but I don't see any other course.
17:18:58 GregoryNoel I don't think the OP has any more info.
17:19:11 garyo-home How about ask him for the config log.
17:19:51 GregoryNoel huh. Somebody named "sharing" just opened the spreadsheet. Is that you, David?
17:19:57 garyo-home Or whether it's all in the same run or separate runs. And to please post the SConstruct.
17:20:30 GregoryNoel OK, but not me, I'm on holiday. Can you take it?
17:20:38 garyo-home Sure.
17:20:51 GregoryNoel garyo, research, done
17:21:01 GregoryNoel 1675?
17:21:05 david__ I don't know if sharing is me. Maybe it is, I can't connect to gmail, so I am read only...
17:21:38 garyo-home 1675: wine bug, close.
17:21:52 GregoryNoel done
17:22:01 GregoryNoel 2089
17:22:39 GregoryNoel I think the two-variable solution is the right course, but when?
17:22:48 garyo-home enhancement req: 2.x p3
17:22:59 GregoryNoel Hmmm.... OK
17:23:13 GregoryNoel wait, 2.x? Not 1.x?
17:23:20 garyo-home I could go with that.
17:23:41 garyo-home It's supposed to be really simple, right? Just pass the flag to compiler?
17:23:44 GregoryNoel I think it needs to be sooner rather than later, and it doesn't look that complex.
17:23:49 garyo-home ok, 1.x.
17:23:54 GregoryNoel Two flags, yeah.
17:24:09 GregoryNoel p3?
17:24:30 garyo-home that's my default
17:24:39 GregoryNoel OK, for Steven?
17:24:49 garyo-home yes
17:24:54 GregoryNoel 1.x, p3, steven, done
17:25:01 GregoryNoel 2095?
17:25:43 GregoryNoel 1.x+symlink, p4, me
17:25:57 garyo-home Right, I think your ssheet comment is good.
17:26:20 GregoryNoel It's how I'd expect it to work {;-}
17:27:01 GregoryNoel no other comments? Done then?
17:27:18 david__ I don't understand the issue, never use symlinks in builds :)
17:27:20 garyo-home ok.
17:27:31 GregoryNoel done
17:27:36 GregoryNoel 2096?
17:27:40 garyo-home david__: not sure we'll ever handle them 100% perfectly, but we can do better.
17:27:54 garyo-home 2096: research.
17:28:06 GregoryNoel I'm game
17:28:08 david__ Is it something scons is supposed to support or not ?
17:28:19 GregoryNoel Good question.
17:28:27 GregoryNoel It should support it, but how?
17:28:50 GregoryNoel Should all configuration be global? Or should all configuration be local?
17:28:34 garyo-home Each one independently, yes. Together: probably should, just haven't thought it through.
17:28:57 GregoryNoel Or some combination of both?
17:29:04 GregoryNoel It's not obvious.
17:29:06 david__ gary: maybe VariantDir is not the right way, but I think scons should support the notion of a self contained build directory for everything scons ever spits out
17:29:08 garyo-home Actually now that you mention it, I use both, and expect the sconf files to be under root, not in the build dir. But I do all my sconf from the SConstruct.
17:29:42 GregoryNoel That's why I posed the question
17:29:40 garyo-home david__: you can use --srcdir for that. mkdir build; cd build; scons --srcdir ..
17:30:13 garyo-home anyway, we shouldn't design it here & now.
17:30:19 garyo-home research, steven.
17:30:26 GregoryNoel True... agree
17:30:41 david__ ok.
17:30:39 GregoryNoel 2097?
17:30:59 david__ The problem of 2097 is different than 2096, I believe
17:31:06 david__ but if we don't support 2096, then...
17:31:13 GregoryNoel Question here is whether this ends up the same issue as 2096
17:31:20 david__ The problem is in TryRun
17:31:45 david__ Building and linking works fine, but the run the target is not aware of BuildDir
17:31:53 GregoryNoel But TryRun is part of SConf, and it should figure out where things should go.
17:32:03 garyo-home 2097 doesn't say anything about TryRun ??
17:32:32 GregoryNoel In the description, I think
17:33:02 david__ Argh, you're right gary, sorry, I mixed up things
17:33:02 GregoryNoel Both are about where the build tests are made and where the results go
17:33:13 garyo-home huh? 2097 = scons is confused when configuration checks are put into build dir set by VariantDir ?
17:33:28 david__ The problem of 2097 is with the sconsign file
17:33:35 garyo-home david__: right.
17:33:40 david__ when sconsign is put into the build-dir
17:34:04 garyo-home david__: actually, when it's *not* in the build dir things can get confused.
17:34:35 david__ Well, in that case, when build dir is not used, it works as expected ? What do you mean ?
17:34:43 garyo-home but I agree it should check that the files still exist before thinking the file is uptodate.
17:35:14 garyo-home no, I mean I usually put the .sconsign file into the build dir. Then removing the build dir removes the .sconsign file and I don't have this problem.
17:35:31 david__ ah
17:35:48 garyo-home Anyway, it is a bug I think; scons should not think a nonexistent file is up to date!
17:35:53 david__ yes
17:36:14 GregoryNoel so, research, steven?
17:36:15 garyo-home 1.x p3 IMHO; who should get configure things?
17:36:23 garyo-home steven I guess
17:36:49 GregoryNoel I think these two should be kept as a pair and assigned the same place
17:36:52 david__ how do you decide between 1.x and 2.x ?
17:37:01 GregoryNoel WAG
17:37:10 garyo-home :-)
17:37:18 david__ WAG meaning ?
17:37:32 GregoryNoel Oh, sorry, that's an anagram of "wild-ass guess"
17:37:33 garyo-home 1.0: severe bug. 1.x: should be fixed soon, or hi pri enh req. 2.x: everything else.
17:37:45 garyo-home how's that?
17:37:48 david__ ok, one new acronym for me
17:38:01 GregoryNoel yes, acronym
17:38:17 garyo-home I don't think 2096 and 2097 are the same; they can be assigned differently.
17:38:28 GregoryNoel You forgot 1.0.x and future.
17:39:11 garyo-home I don't know what to say about 1.0.x; future is so we don't lose track of cool ideas that are not currently practical.
17:39:29 david__ I think 2097 is more sever than 2096, no ?
17:39:40 david__ 2096 just does not work. But 2097 is quite surprising
17:39:44 garyo-home david__: and probably easier to fix.
17:39:55 garyo-home (2097 easier than 2096)
17:40:05 david__ yes
17:40:05 GregoryNoel Both have to do with location of files
17:40:20 GregoryNoel I'll bet if you fix one, the other is 90% done
17:40:41 garyo-home If you fix 2096, 2097 might go away, but not the other way round.
17:40:55 garyo-home anyway, how about a note in each one referring to the other.
17:41:00 GregoryNoel works
17:41:20 david__ I don't understand the implications enough, so nothing to say
17:41:26 GregoryNoel so you wanted 1.x p3: I'll go for that
17:41:33 david__ sorry, I meant for issues 2096-2097
17:41:56 garyo-home Greg: 2097 1.x p3? yes.
17:42:04 GregoryNoel done
17:41:18 garyo-home 2098: has patch, good!
17:42:23 GregoryNoel 2098, I'm not sure the patch will fly as is
17:42:40 garyo-home haven't looked at it.
17:42:57 GregoryNoel It's too simple; special case for python and java, nothing else
17:43:19 GregoryNoel so if you had -python -tcl as parameters, it would fail.
17:43:33 garyo-home I see. OK, so pass back to OP with comments?
17:43:40 GregoryNoel I mean SCons would fail, since it wouldn't get the output right.
17:43:56 garyo-home Right, understood.
17:43:58 GregoryNoel Hmmm... Sure, we can try that; review next week?
17:44:05 garyo-home Ask OP to improve patch and resubmit.
17:44:10 GregoryNoel done
17:44:14 garyo-home I'll do it.
17:44:43 GregoryNoel somebody will have to do most of them; I won't be around
17:45:15 garyo-home OK, if you email me the irc log I'll do the data entry.
17:45:41 GregoryNoel I can set up the IRC page; I have the tools, but that will be pretty much it.
17:46:24 garyo-home ok, that's fine. I'll look there.
17:46:31 GregoryNoel 2100?
17:46:37 garyo-home I may have logging enabled here too. OK, 2100...
17:47:18 garyo-home Saw this on the ML. Steven understands it. I think should be fixed soon; it's a regression.
17:47:29 GregoryNoel I don't agree.
17:47:37 garyo-home ok?
17:47:37 david__ How supporting # in LIBS makes linking more platform independant ?
17:47:55 GregoryNoel Not a platform-dependent issue.
17:47:57 garyo-home umm. never mind, I was looking at 2099. Sorry.
17:48:16 GregoryNoel Ah, we skipped one...
17:48:21 GregoryNoel 2099!
17:48:34 david__ The comment of 2100 says it would make it easier to support platform independant linking, so I guess I am missing something
17:48:56 garyo-home ok, 2099 I say 1.0 or 1.0.x, p2. Regression.
17:49:04 GregoryNoel Let's finish 2100 and then go back
17:49:10 garyo-home ok
17:49:26 * stevenknight (n=stevenkn@nat/google/x-bf5612cd2f2152ca) has joined #scons
17:49:34 stevenknight hey, anyone still here?
17:49:38 garyo-home Hi, Steven!
17:49:42 GregoryNoel No, we've all left
17:49:58 GregoryNoel We're arguing over 2100
17:50:15 stevenknight sorry about that, got pulled into one of those urgent impromptu meetings
17:50:15 garyo-home 2100: if it's a pathname, why not use ./#foo.so if the libname is foo and you don't want it turned into top-relative?
17:50:35 garyo-home steven: we just gave you all the bugs, p1, 1.0.
17:50:39 GregoryNoel It's _not_ a pathname!
17:50:42 stevenknight excellent
17:50:44 garyo-home ;-)
17:50:54 GregoryNoel It's a library name.
17:51:04 garyo-home He says path name.
17:51:15 stevenknight historically, it's been a library name
17:51:27 GregoryNoel If you put a bare string in LIBS, it gets wrapped.
17:51:28 stevenknight my question is: is there a reason why it can't also refer to an actual *library*?
17:51:33 stevenknight either as a node or a path name?
17:51:52 GregoryNoel How can you tell? Library names can be anything, including 'm'
17:52:03 garyo-home I use Nodes, but I think abs pathnames work too. Maybe # is turning it *into* a pathname?
17:52:20 garyo-home Greg: begins with / or is a Node.
17:52:33 stevenknight garyo-home: Nodes in LIBS, or Nodes in the SOURCES list?
17:52:38 GregoryNoel I can't check quickly, but I'm not sure I believe it.
17:52:40 garyo-home LIBS.
17:52:56 garyo-home I know Nodes work, not sure about abs paths.
17:53:01 GregoryNoel And what if it begins C: ?
17:53:09 stevenknight I don't think abs paths work
17:53:18 GregoryNoel I don't either
17:53:19 stevenknight I think strings all just get a -l prepended (on Linux)
17:53:20 garyo-home ok, I defer to you.
17:53:36 garyo-home In which case what's the bug?
17:53:44 GregoryNoel invalid
17:54:04 stevenknight You can say env.Program('#foo.c', LIBS=['#bar.lib'])
17:54:16 stevenknight and the target gets interpreted into a Node
17:54:18 stevenknight and the LIBS doesn't
17:54:23 GregoryNoel and the first is a file and the second is the name of a lib
17:54:26 stevenknight and that looks inconsistent to users
17:54:40 garyo-home Steven: but File('#bar.lib') does. I think it's correct as is.
17:54:42 stevenknight if it's only for the name of a lib then why can you use a Node therE?
17:55:09 garyo-home sorry, you have to know the path to use File(...) so it's not as easy as I said above.
17:55:19 stevenknight exactly
17:55:23 garyo-home So you have a point.
17:55:38 GregoryNoel Why doesn't File(#name) work?
17:55:52 stevenknight it does
17:55:53 garyo-home Greg: because typically name is in LIBPATH, not here.
17:56:02 stevenknight but why do you have to specify File() for the target and not the LIBS?
17:56:19 GregoryNoel because it's a library name
17:56:29 stevenknight then why does a Node work there?
17:56:45 garyo-home special dispensation, escape hatch.
17:56:47 stevenknight okay, ta,e this out of LIBS
17:56:51 GregoryNoel There's a programing language with sharp in the name; I can believe a library name that starts with a sharp
17:57:19 stevenknight should this behave the same as CPPPATH?
17:57:34 garyo-home Does it?
17:57:43 stevenknight i'm not sure, actually :-)
17:58:01 GregoryNoel if it ends in PATH, it's a list of file locations; they have Node() applied automatically
17:58:15 garyo-home It's *slightly* different because libs typically have pre and suffixes, and you specify them without those.
17:58:21 stevenknight we do have a test for absolute paths w/CPPPATH, so it looks like that works
17:59:04 stevenknight and we have tests for '#' as well, so that works
17:59:17 stevenknight true re: prefixes and suffixes
18:00:07 garyo-home hm, does sound like it's inconsistent though. What's your recommendation? Make abs paths and # paths get turned into nodes by looking on LIBPATH?
18:00:22 garyo-home (sorry, not by looking on any path)
18:00:20 stevenknight let me be real concrete: the use case I'm running into here is someone who not only put '#foo.lib' in LIBS, but also put just 'bar.lib' without the #
18:00:42 stevenknight well, now I'm going to play devil's advocate and argue with myself
18:01:02 stevenknight because that does open up the can of worms about where on the slippery slope we draw the line
18:01:13 stevenknight which I think might be underlying Greg's concern about this
18:02:17 GregoryNoel YES
18:01:54 garyo-home I'd be comfortable with abs paths; no existing lib could have such a name.
18:02:12 stevenknight yeah, abs paths, and '#'
18:02:34 stevenknight i'm kind of bugged by the fact that LIBS=['foo.lib'] gets turned into '-lfoo.lib'
18:02:44 garyo-home The suffix problem
18:02:48 stevenknight but I don't know how to avoid that without getting really hairy about suffixes
18:02:49 stevenknight yes
18:03:08 garyo-home right, what if they really wanted foo.lib.lib
18:03:26 garyo-home or whatever
18:03:26 GregoryNoel You begin to see the issue
18:03:27 stevenknight exactly
18:03:42 stevenknight so I'm not unsympathetic to both sides
18:03:51 garyo-home but that's a different issue, right? We're only talking about / and # and maybe C:/
18:04:24 GregoryNoel I say stick to your guns, keep it simple
18:04:36 garyo-home You kind of want the reverse of what Node does: something to say pass this exactly as is. But Greg's right, one thing at a time.
18:04:43 GregoryNoel and don't start down the slippery slope
18:04:58 GregoryNoel not with /, not with #, and not with C:
18:05:56 garyo-home Greg: be specific please?
18:06:15 GregoryNoel Huh? I think the issue is INVALID
18:06:27 GregoryNoel it works exactly as it's supposed to work
18:06:48 GregoryNoel and we shouldn't be in the business of being too smart
18:07:07 GregoryNoel about what the user (luser?) is "trying" to do
18:07:15 david__ Definitely
18:07:29 stevenknight even when not being smart means we end up confusing the user?
18:07:38 david__ Many tools in python around build/distribition try to be smart, and fail miserably
18:07:50 GregoryNoel That's what the FAQ is for, and the mailing lists
18:08:05 GregoryNoel If there's really an issue, put it in the documentation
18:08:07 garyo-home ... and the workaround is always use Node() in those cases? I think it's pretty clear what someone means if they put a / first.
18:08:37 GregoryNoel Pretty clear to whom?
18:08:44 garyo-home the user.
18:08:55 garyo-home They don't want -l/foo/bar/baz.lib.
18:09:21 GregoryNoel I think you're likely to be correct, but somebody just might.
18:10:13 david__ It is easier to find the workaround than understanding why it does not work in some cases because of 'magic'
18:10:38 GregoryNoel Instead of INVALID, how about changing the documentation to be clear about it? With an example?
18:10:17 garyo-home I'd be (just barely) OK with documenting it in LIBS. Use Node() if you want to pass a filename.
18:10:52 GregoryNoel File() in this case...
18:11:06 david__ That sounds like the most reasonable thing to do to me
18:11:11 garyo-home OK.
18:11:13 stevenknight okay, hang on re: File()
18:11:36 * GregoryNoel is hanging....
18:11:37 stevenknight if you're going to use File() then you have to spell out everything
18:11:43 stevenknight which means you end up with things like:
18:11:51 garyo-home But you already are in these cases.
18:12:12 stevenknight LIBS = ['$LIBRARY_DIR/foo/${LIBPREFIX}bar{$LIBSUFFIX}')
18:12:34 GregoryNoel Huh? Who ever said that?
18:12:38 stevenknight sorry, LIBS=[File('')]
18:12:46 stevenknight that's the real-world use case I'm working with right now
18:12:56 garyo-home right, you need the pre/suffixes for OS independence.
18:13:29 garyo-home But you were planning on passing a full pathname anyway, right?
18:14:07 GregoryNoel I see; File() doesn't interpolate the variables? What about env.File()?
18:14:07 GregoryNoel hello?
18:14:25 stevenknight yes, env.File()
18:14:40 stevenknight sorry, I'm translating between a verbal argument and an IRC argument about this real time... :-)
18:15:02 GregoryNoel (I'm seeing some real long latencies between when I send and when it shows up; if I seem out of sync, forgive me)
18:15:09 stevenknight np
18:15:16 garyo-home ok.
18:15:23 stevenknight fair point about needing to specify the file name
18:15:41 david__ If File does not interpolate, should it be done in File or a Lib subclass ?
18:15:56 stevenknight no, you use env.File(), which does interpolate
18:15:58 GregoryNoel In theory, env.File() should interpolate. Doesn't it?
18:15:59 garyo-home I think having scons do pre/suffix processing on an abs or # pathname would be gross. Steven, you're not suggesting that?
18:15:59 stevenknight i mistyped the first example
18:16:07 stevenknight no, i'm not
18:16:29 garyo-home greg: yes.
18:16:38 stevenknight okay, how about if we table this
18:16:43 stevenknight give it to me to research
18:16:55 GregoryNoel I'll agree
18:16:59 garyo-home ok.
18:16:58 stevenknight I'll kick around ideas here with the real-world sufferers
18:17:17 garyo-home :-)
18:17:21 stevenknight and we don't discuss it again until (or if) there's a tangible proposal for changing the behavior
18:17:30 stevenknight whew!
18:18:16 GregoryNoel Back to 2099? (which we accidentally skipped?)
18:18:48 GregoryNoel Hello?
18:19:07 garyo-home Saw this on the ML. Steven understands it. I think should be fixed soon; it's a regression.
18:19:10 garyo-home 1.0.x, p2.
18:19:30 GregoryNoel works for me
18:19:31 stevenknight done
18:19:43 GregoryNoel 2101: Consider a Solaris system with the Sun C compiler installed but without GCC installed.
18:19:43 GregoryNoel There are three Tools specified for the C compiler: ['aixcc', 'gcc', 'cc']
18:19:43 GregoryNoel Reading that list, one assumes that the AIX is chosen in preference to GCC, which in turn is chosen in preference to a random compiler named 'cc' (which is what the documentation says), but that's not what actually happens.
18:19:43 GregoryNoel All three Tools recognize 'cc' as a possible name for their compiler, so all three of them detect the 'cc' command, all three return true from exists(), and all three are generated.
18:19:43 GregoryNoel In other words, although the _last_ Tool "wins," any setup done by the earlier tools (and not overwritten by later tools) is still around.
18:19:43 GregoryNoel In this case, the latter Tools don't change anything set up by the earlier tools (more accurately, they overwrite with the same values), so the configuration "works" and users can compile.
18:19:43 GregoryNoel Fixing this would require that each Tool detect that its tool type (C compiler in this case) had already been configured and return 'False' from exists().
18:19:43 GregoryNoel Not only would this be faster, probably by a lot (only one Tool generated), it wouldn't depend on blind luck that the options are compatible.
18:19:43 GregoryNoel The problem is that this isn't backward compatible. I believe it's what the semantics were supposed to be, but it's not what is implemented currently.
18:19:43 GregoryNoel In particular, our most common example "tools=['default','mingw']" no longer would work and would have to be changed to "tools=['mingw','default']" to get the effect intended.
18:19:43 GregoryNoel (Or to "tools=['mingw','default','mingw'] so it works either way.)
18:19:43 GregoryNoel So the real question before us in this issue is which semantics should be supported in the short term (first "wins" or last "wins").
18:19:43 GregoryNoel In the longer term, the toolchain rework will make the winner the first one, so right now we can choose to match the documentation (and be incompatible) or match the implemented semantics (and change the documentation).
18:19:43 GregoryNoel I'm torn. I feel the documented semantics are the right choice, but it would be a _big_ disruption.
18:20:21 stevenknight damn, Greg, your typing sure got fast all of a sudden!
18:20:32 stevenknight :-)
18:20:35 garyo-home rofl
18:20:59 GregoryNoel I practiced all week {;-}
18:21:51 david__ Concerning tools, my impression is that people who need some control just do it manually, no ?
18:22:00 stevenknight ah, I didn't realize we're incompatible with our own doc
18:22:39 GregoryNoel Yes, we seem to be able to apply two different models simultaneously
18:23:04 david__ What is the documented semantics ?
18:23:12 david__ What are, sorry
18:23:26 david__ The one in scons man, or in the code ?
18:23:37 stevenknight my gut is that since there's a good short-term workaround--namely, don't call the tool twice--that it makes more sense to defer this until the toolchain work really does it right
18:24:06 stevenknight ("Doc, it hurts when I do this." "Well, don't do that.")
18:24:06 GregoryNoel The man page says that the first-listed applies. The code says that _all_ are applied.
18:24:33 stevenknight whoa, wait, I think you're looking at two different lists...?
18:24:55 GregoryNoel (In fact, I don't know why it fails. It should just be generated twice.)
18:25:25 garyo-home From the stacktrace, the generate doesn't fail, it fails while compiling cause something gets busted.
18:25:28 GregoryNoel What two different lists?
18:25:46 stevenknight oh, wait, I'm sorry, I thought you were thinking of the preferences in Tool/__init__.py
18:26:13 garyo-home I'm trying to find the man page doc for this & failing. Greg?
18:26:29 stevenknight where does it say only the first is applied?
18:26:30 GregoryNoel That may be another bug, not related
18:26:52 david__ I don't remember having seen this either ? I thought scons manual said the last one is applied ?
18:27:14 stevenknight oh, shoot, I hate to be late to the party *and* leave early
18:27:16 GregoryNoel Hmmm... Doesn't it say that local compilers are chosen over FOSS toolchains?
18:27:17 garyo-home I don't see anything about lists of tools there.
18:27:19 stevenknight but I'm still at work and taking the late shuttle
18:27:26 stevenknight so I have to leave and get over to the stop
18:27:34 garyo-home Yes, but nothing about lists.
18:27:55 stevenknight I'll connect again once I'm there in case anyone's still going
18:28:00 stevenknight but don't feel obligated on my account
18:28:02 garyo-home Closest is the MingW section.
18:28:05 stevenknight later
18:28:09 garyo-home bye
18:28:09 * stevenknight has quit ("Leaving")
18:29:01 garyo-home I don't think we can do anything about this actual bug now in any case. You have to allow tools to be reapplied in general.
18:29:43 GregoryNoel I'm not finding any obvious keywords, but then I'm a terrible searcher.
18:30:16 GregoryNoel Wait, it says "On posix and cygwin platforms the GNU tools (e.g. gcc) are preferred by SCons, on Windows the Microsoft tools (e.g. msvc) followed by MinGW are preferred by SCons, and in OS/2 the IBM tools (e.g. icc) are preferred by SCons."
18:30:36 GregoryNoel That's not what's reflected in the code.
18:30:41 garyo-home I don't see a good short term fix for this bug, unless the mingw tool itself is creating a broken env the 2nd time. I say it should wait for toolchain redo.
18:30:51 GregoryNoel works for me
18:31:26 GregoryNoel let Steven research whether there's a different bug in play that's tickled by re-applying mingw
18:31:42 garyo-home good.
18:32:25 GregoryNoel 2102, stevenknight, VisualStudio?
18:32:28 garyo-home 2102, more Visual Studio, lump in w/ the others. Could apply his patch but parsing vsvars.bat will be so much better.
18:32:37 garyo-home agreed.
18:32:37 GregoryNoel concur
18:32:43 david__ Argh, I should have asked Steven
18:32:48 david__ I have the code for this
18:33:07 david__ parsing vsvarsall.bat also makes possible cross compilation to x64, in theory
18:33:41 GregoryNoel He has the code, yes?
18:33:41 garyo-home david__: yes. Please post your code on the dev list if you can. And you're right, it also solves issue 2013.
18:33:43 david__ I am not sure I understand 2103, but I don't see why parsing .bat would not work in his case
18:34:07 garyo-home sorry, yes 2103 not 2013
18:34:07 david__ @gary: the only reason why I did not post the code publicly is because of licensing
18:34:16 david__ But that may be red-herring
18:34:34 david__ I don't understand the difference between python license and scons (MIT) license
18:34:40 garyo-home ok. See what you can do then. Do you have a good way to decide which bat file to run?
18:34:41 GregoryNoel If there could be a licensing issue, we can't look at it.
18:35:22 GregoryNoel MIT license is more liberal, has fewer restrictions.
18:35:37 GregoryNoel IANAL, but I believe they're compatible.
18:35:34 david__ @Greg: my code is inspired by distutils. But the code is a rewrite. What shall I do ?
18:35:59 david__ (I did not get answer from the original commiter in distutils)
18:35:59 garyo-home If it's a rewrite I think we are safe enough.
18:36:05 david__ It is
18:36:12 GregoryNoel If you wrote it, pretty much from scratch, it's yours to assign as you choose
18:36:14 david__ Variable are different, functions are different
18:36:36 david__ Parsing is different, too
18:36:51 garyo-home That seems pretty clear that it's your work, not derived.
18:36:53 GregoryNoel Probably (IANAL) good enough
18:37:04 garyo-home Just inspired. But IANAL either...
18:37:19 david__ Inspired and derivative can only be decided in court, right ?
18:37:26 garyo-home :-/
18:37:34 GregoryNoel unfortunately
18:37:46 david__ I don't see python developer assigning me to court, though
18:37:56 garyo-home No I think you're right.
18:38:12 GregoryNoel Since they'd have to bring action in France or Japan, I doubt it
18:38:35 david__ To answer the question about vsvars.bat: I use the same technique as distutils here. I first look at the registry
18:38:52 david__ and if the .bat is not found, I read the VS*COMMON fenv variable
18:39:03 david__ Since I can check for the existence of a file
18:39:11 david__ even stalled registry keys do not break things
18:39:17 garyo-home OK, makes sense. For issue 2013, might have to look in the 32-bit registry instead. I can help w/ that.
18:39:32 david__ I am not a windows programmer
18:39:37 garyo-home I am.
18:39:42 david__ good
18:39:53 david__ So shall I consider the code to be safe to put in scons svn ?
18:40:03 david__ Shall I wait for Steven answer, maybe ?
18:40:13 GregoryNoel Nag him
18:40:19 david__ Ok
18:40:20 garyo-home Let's try you & me & Steven to make a test version of this in the next few weeks. Yes, wait for Steven to concur.
18:40:48 GregoryNoel Does that get us to 2104?
18:40:54 garyo-home I think so.
18:41:10 david__ The easy fix is easy :)
18:41:31 garyo-home Is there any risk? Does it change the user command line?
18:41:33 david__ But this can be done in a common module between msvc and posix C compilers ?
18:41:45 GregoryNoel I suspect it's a real defect from the fix for CCFLAGS, et.al.
18:42:09 david__ @Gary: anyway, it means that behavior of msvc is not consistent with all others, which sounds like a bug to me
18:42:47 garyo-home @david: maybe not, but we shouldn't change it before 1.0. Would have to be after if it's going to change behavior.
18:43:04 garyo-home Of course (devil's advocate) if it's going to cause recompiles, maybe better now than later.
18:43:25 GregoryNoel Steven says 1.0.x, I say 1.0; either way, immediately
18:44:02 garyo-home OK, fine w/ me. p3 or p4.
18:44:15 GregoryNoel which? I'll go with 1.0.x
18:44:30 david__ I don't understand why we should not change buggy behavior, which is also not consistent with documentation ?
18:45:02 GregoryNoel We should, but we don't want to take chances with disrupting what's working now
18:45:01 garyo-home 1.0 is very nearly ready; we should not destabilize it in any way. 1.0.x is the first possible place.
18:45:20 GregoryNoel so 1.0.x p3?
18:45:25 garyo-home ok.
18:45:28 GregoryNoel done
18:45:34 GregoryNoel When shall we all meet again?
18:45:34 GregoryNoel In thunder, lightning, or in rain?
18:45:34 GregoryNoel Where the place? ...
18:45:34 GregoryNoel I'll be on holiday next week, but I believe it's Internet-connected, so I should be able to attend remotely, either Monday or Tuesday, so it's up to you guys. I still don't know if mail will work.
18:45:58 david__ @Gary: understood.
18:46:05 * stevenknight (n=stevenkn@69.36.227.130) has joined #scons
18:46:16 garyo-home My family is getting a little grumpy about me doing this every week. But I'll be around both Monday and Tuesday.
18:46:23 stevenknight hey there, anyone still around from the bug party?
18:46:26 stevenknight oh, there you go
18:46:28 garyo-home Hi Steven, we're talking about schedule for next wk.
18:46:37 david__ For me, this time is fine
18:46:48 david__ sooner is ... too soon
18:47:10 garyo-home Time's good w/ me. Monday is the usual day; that OK?
18:47:10 stevenknight garyo-home: a different time would help?
18:47:23 stevenknight Monday's fine with me
18:47:48 garyo-home @steven: if it were to start around now it might help me. But I know that's tough for some.
18:47:49 david__ same time ?
18:48:20 garyo-home Let's plan on same time as usual. I'll try to do my homework properly next time. Too bad we didn't get to any of the tickets I commented on :-/
18:48:44 david__ Same time as now would be fine for me
18:48:52 david__ if it is more convenient for you
18:48:54 stevenknight okay, same time Monday next week
18:48:58 GregoryNoel Now == noon?
18:49:08 david__ For me, now is 10:30 a.m
18:49:30 GregoryNoel (doing arithmetic in head) Ah, yes
18:49:34 david__ There is 14 hours difference with West Coast if I remember right
18:49:52 GregoryNoel you're UTC+9
18:50:03 david__ Yes
18:50:03 stevenknight where?
18:50:08 garyo-home I don't want to cause trouble but starting at 9:30 or 10 my time would be easier for me, I'm GMT+4 (EDT)
18:50:10 GregoryNoel Japan
18:50:21 stevenknight ah
18:50:22 GregoryNoel Er, Nippon
18:50:24 garyo-home i.e. start around now
18:50:36 garyo-home Steven, what about you?
18:50:36 david__ now is fine by me
18:51:03 stevenknight this time works well, but i'm pretty flexible
18:51:14