Please note:The SCons wiki is in read-only mode due to ongoing spam/DoS issues. Also, new account creation is currently disabled. We are looking into alternative wiki hosts.
   1 16:57:18 *	bdbaddog (~bdeegan@adsl-71-131-1-95.dsl.sntc01.pacbell.net) has joined #SCONS
   2 17:00:43 <sgk>	hey guys
   3 17:01:00 <bdbaddog>	Greetings.
   4 17:01:06 *	Jason_at_Intel (~chatzilla@12.18.240.208) has joined #SCONS
   5 17:01:53 <GregNoel>	Hi, I can't stay the entire time, so if we're going to get started, we should do it soon.
   6 17:02:04 <Jason_at_Intel>	hello
   7 17:02:16 <sgk>	let's go, gary indicated he has a conflict
   8 17:02:22 <GregNoel>	2689 clear preference for 2.1 p2, but who can do it?
   9 17:03:07 <sgk>	sigh...  probably belongs in my camp, i probably know that code best
  10 17:03:17 <GregNoel>	done
  11 17:03:26 <GregNoel>	2690 Consensus on "asap" but that needs to be defined (also "who").
  12 17:03:49 <sgk>	gary suggested using callable(), give it to him?
  13 17:03:59 <GregNoel>	works for me
  14 17:04:16 <Jason_at_Intel>	agree
  15 17:04:24 <GregNoel>	done
  16 17:04:27 <GregNoel>	2691 Done by Gary (thanks!)
  17 17:04:27 <GregNoel>	2692 Technically invalid.  Also technically a dup of 2536.  I agree with Steven that a separate InstallDir() is not the way to go.  So, is this sufficiently urgent that we should do it independently of 2536?  I'm inclined to treat it as a dup.
  18 17:05:06 <sgk>	i'd go with dup, unless someone feels strongly enough to take it on sooner
  19 17:05:13 <Jason_at_Intel>	I think this shows a need to handle structure in the node lists
  20 17:05:42 <sgk>	Jason_at_Intel:  that sounds right
  21 17:05:58 <GregNoel>	This has nothing to do with node lists; it's about structuring a destination directory.
  22 17:06:29 <GregNoel>	Yes, zip files should be structured in the same way, but that's not the point here.
  23 17:06:34 <Jason_at_Intel>	ya... like Zipfile... remember you idea with tuples
  24 17:07:12 <sgk>	anyway, it's big enough that i doubt anyone's going to pull a rabbit out of their hat for it soon
  25 17:07:19 <Jason_at_Intel>	I agree a new function is the wrong way to go.. I am only saying that a fundamental fix is needed in SCons.. once that is done a large set of issues go away
  26 17:07:23 <sgk>	so dup 2536 should be fine
  27 17:07:31 <GregNoel>	OK, dup it is; done
  28 17:07:35 <GregNoel>	2693 I'm willing for it to be 2.x p3, so there's consensus there, but who should do it?  And should it be activated by catching the exception if the unlink() fails?
  29 17:08:19 <sgk>	Jason_at_Intel:  since you already dealt with the os.stat() issue in Parts, could you take this one?
  30 17:08:24 <Jason_at_Intel>	I have a fix in Parts with an unlink override that will do this
  31 17:08:37 <GregNoel>	done
  32 17:08:49 <sgk>	if you want to implement it in a way that melds nicely with Parts, that'd be cool
  33 17:08:58 <Jason_at_Intel>	I guess... can we get that patch ( maybe tweaked in this case) that i put i dev list in SCons?
  34 17:09:33 <sgk>	which one?  i don't see why not
  35 17:09:50 <Jason_at_Intel>	it would this one... getting link
  36 17:10:36 <Jason_at_Intel>	http://scons.tigris.org/ds/viewMessage.do?dsForumId=1268&dsMessageId=2673518
  37 17:11:02 <Jason_at_Intel>	this will allow the base of what is needed to get hard links and symlinks working in SCons for windows
  38 17:11:53 <sgk>	okay, but that's orthogonal to 2693, yes?
  39 17:11:54 <Jason_at_Intel>	we can add the tweaked CCopy builder as well if you like :-) ( as my copy has the reporting API in Parts for --verbose ability)
  40 17:12:09 <sgk>	so let's get through the bug list first before discussing those details
  41 17:12:38 <Jason_at_Intel>	only in that i would then add the unlink overide to retarget readonly files as well
  42 17:12:16 <GregNoel>	2694 (First thing I'd look for is spelling errors.)
  43 17:13:10 <Jason_at_Intel>	Greg I would agree
  44 17:13:55 <Jason_at_Intel>	They might be an issue with MSVS_VERSION
  45 17:14:03 <sgk>	2694:   spelling errors in what?  he posted his SConstruct, and MSV[CS]_VERSION are spelled correctly, at least...
  46 17:14:45 <GregNoel>	sgk, I'll take your word for it.
  47 17:14:51 <sgk>	yeah, he posted it
  48 17:14:41 <Jason_at_Intel>	there should be a simple test case that can verify this.
  49 17:15:38 <sgk>	bdbaddog, do you have cycles to investigate?  if not, how about if we ask gary to follow up, since he already replied once
  50 17:15:41 <Jason_at_Intel>	BDog?
  51 17:16:20 <bdbaddog>	hmm. I can take a first pass at it.
  52 17:16:40 <bdbaddog>	just checking that MSVSProject is reading/doing anything with those variables..
  53 17:16:44 <GregNoel>	research?  If so, then what priority?
  54 17:16:47 <bdbaddog>	it could be broken from the refactoring.
  55 17:16:54 <sgk>	p3?
  56 17:17:11 <bdbaddog>	p3
  57 17:17:14 <GregNoel>	works for me
  58 17:17:19 <sgk>	cool, thanks
  59 17:17:17 <GregNoel>	2695
  60 17:18:50 <GregNoel>	I'm almost positive Action() does the right thing (there are tests for it); what did you mean here?
  61 17:18:53 <sgk>	2695:  looking to see if my diagnosis looks in the ballpark
  62 17:19:48 <sgk>	yeah, looks right
  63 17:20:16 <sgk>	GregNoel:  you're right, Actions know how to rebuild in response to changes to variables, but only if they know what variables are used
  64 17:20:30 <sgk>	command-line strings track the changes for free because we expand them
  65 17:20:39 <sgk>	but Python function actions don't get expanded that way
  66 17:20:57 <sgk>	so they have to be told what construction variables the Python function will look at when building its target
  67 17:20:57 <GregNoel>	Ah, you mean MSVSProject() doesn't provide the variables?
  68 17:21:00 <sgk>	yeah
  69 17:21:37 <GregNoel>	So yes, easy fix: just provide the variables.  Who does it?
  70 17:21:35 <sgk>	so give it to me, should be pretty trivial
  71 17:21:43 <GregNoel>	done
  72 17:22:01 <GregNoel>	2696 Er, it's not O(1), but I agree with Gary that the size should be included.
  73 17:22:53 <Jason_at_Intel>	I think it would be nice if we could reuse existing logic
  74 17:23:21 <sgk>	the question is how?
  75 17:23:42 <sgk>	we have this Unlink() action that really should only be called if necessary
  76 17:23:48 <sgk>	instead of every time
  77 17:23:55 <Jason_at_Intel>	and i think the link unlink can be used for more than it is going forward with the fixes i have for win32
  78 17:25:40 <Jason_at_Intel>	so it might be good to factor the checking "decider" logic in a different way in the node objects
  79 17:25:44 <sgk>	the architectural issue (iirc) is that the duplicate logic is kind of handled as a side effect of examining source files
  80 17:26:22 <sgk>	not as a direct action in the DAG walk, which is probably where it should really happen
  81 17:26:36 <sgk>	so the goal of re-using it is good, but would take a lot more work
  82 17:27:06 <sgk>	and i'd hate to not give people a good optimization in the meantime
  83 17:27:18 <Jason_at_Intel>	well that seems simple then
  84 17:27:29 <sgk>	we should still be able to refactor it in the future along the lines you're suggesting
  85 17:27:32 <Jason_at_Intel>	take the fix.. and note that this needs to be cleaned up
  86 17:27:45 <sgk>	yeah
  87 17:27:58 <sgk>	oh, i'll open up a separate issue to track that clean up
  88 17:28:01 <GregNoel>	decision?
  89 17:28:12 <sgk>	so...  2.1 p3 sgk?
  90 17:28:30 <Jason_at_Intel>	+1
  91 17:28:32 <GregNoel>	hmmm...  Yeah, that seems OK.
  92 17:28:34 <GregNoel>	done
  93 17:28:53 <GregNoel>	2697
  94 17:29:05 <sgk>	bdbaddog or Jason_at_Intel, can either of you volunteer?
  95 17:29:41 <Jason_at_Intel>	I have code, and stuff to share to help...
  96 17:30:06 <Jason_at_Intel>	however the current msvc tools is beyond me.. as i already have a working version in Parts
  97 17:30:37 <sgk>	can you update the issue with specifics about the registry difference?
  98 17:30:47 <Jason_at_Intel>	Be happy to
  99 17:31:00 <bdbaddog>	I was looking at vc9 vs vc9 express (and for 10) wasn't sure how to detect the diff.
 100 17:31:41 <sgk>	bdbaddog:  if Jason_at_Intel provides that info, would it be pretty straightforward to fix?
 101 17:32:34 <Jason_at_Intel>	r'Software\Wow6432Node\Microsoft\VisualStudio\9.0\Setup\VC\ProductDir',
 102 17:32:36 <Jason_at_Intel>	                    r'Software\Microsoft\VisualStudio\9.0\Setup\VC\ProductDir',
 103 17:32:38 <Jason_at_Intel>	                    r'Software\Wow6432Node\Microsoft\VCExpress\9.0\Setup\VC\ProductDir',
 104 17:32:39 <Jason_at_Intel>	                    r'Software\Microsoft\VCExpress\9.0\Setup\VC\ProductDir'
 105 17:32:42 <bdbaddog>	I'm not sure there's a fix for this, looks invalid.?
 106 17:32:50 <Jason_at_Intel>	first two are pro... second two are express
 107 17:33:01 <bdbaddog>	@jason please post to bug or email to dev list
 108 17:33:12 <Jason_at_Intel>	doing it as we type
 109 17:33:14 <bdbaddog>	if they request an invalid TARGET_ARCH..
 110 17:33:39 <Jason_at_Intel>	well there is another case in this...
 111 17:33:51 <Jason_at_Intel>	there is the 2008 server sdk
 112 17:33:57 <bdbaddog>	anyway .. yes I'll take a look.
 113 17:34:02 <Jason_at_Intel>	this has teh 32-bit -64-bit and ia64 compilers
 114 17:34:07 <Jason_at_Intel>	all looks the same
 115 17:34:12 <sgk>	bdbaddog:  oh, the issue being that the default is to build for the current host arch (64 bits) but he has no 64-bit compiler installed?
 116 17:34:14 <bdbaddog>	we handle sdk separately.
 117 17:34:34 <bdbaddog>	well sort of, if I remember we have a list of SDK's which are valid with diff VC/VS's.
 118 17:34:59 <GregNoel>	decision?  research?  If so, then what priority?
 119 17:35:15 <sgk>	if that's the case, you're right, that does sound invalid
 120 17:35:26 <bdbaddog>	research 2.1 p3
 121 17:35:28 <bdbaddog>	me
 122 17:35:41 <GregNoel>	done
 123 17:35:45 <sgk>	seems like he has an obvious workaround, set TARGET_ARCH to 32 bit, so yeah, 2.1 p3 seems eminently fair
 124 17:35:52 <bdbaddog>	I did finally get a win 7 64 bit machine to play on. so that'll help
 125 17:35:52 <sgk>	I'd be okay with even lower
 126 17:36:02 <GregNoel>	2698 No spreadsheet quorum, so we should bypass this issue if there's no immediate agreement.  (If I have time while I'm writing up the meeting results, I may propose a patch.)
 127 17:36:24 <sgk>	2698:  sounds good
 128 17:36:35 <GregNoel>	so, bypass?
 129 17:36:47 <sgk>	yes
 130 17:36:50 <bdbaddog>	+`1
 131 17:36:51 <GregNoel>	done
 132 17:37:02 <GregNoel>	2699 Again, no spreadsheet quorum.  That said, I think I prefer dup 2536.
 133 17:37:19 <sgk>	i'll go with dup 2536
 134 17:37:31 <Jason_at_Intel>	+1
 135 17:37:40 <sgk>	especially since there's a reference back when the dup occurs, it's not like we lose any additional info
 136 17:37:45 <GregNoel>	done
 137 17:37:49 <GregNoel>	Of the issues up for review, only 1406 could be considered to have a quorum, and that's only if you include Dirk's email.  I propose we assign 1406 to Dirk, make Steven either CC or QA, and turn him loose.
 138 17:38:33 <sgk>	+1, that sounds good
 139 17:38:58 <GregNoel>	sgk, do you want CC or QA?
 140 17:39:19 <sgk>	uh....  both?  QA, if both are superfluous
 141 17:39:33 <sgk>	(both is superfluous?)
 142 17:39:52 <GregNoel>	both can't hurt; the notification email isn't duplicated.
 143 17:39:58 <sgk>	both, then
 144 17:40:03 <GregNoel>	done
 145 17:40:10 <GregNoel>	OK, we're done.
 146 17:40:23 <GregNoel>	And I've got to go, good timing.
 147 17:40:28 <sgk>	ok, thnx everyone
 148 17:40:37 <bdbaddog>	np.. l8r
 149 17:40:50 <GregNoel>	bye, all...
 150 17:41:12 <sgk>	GregNoel, bdbaddog:  'night
 151 17:40:51 <sgk>	Jason_at_Intel:  any more stuff to go over?  I owe you emails from weeks ago
 152 17:41:14 <Jason_at_Intel>	sure
 153 17:41:23 <Jason_at_Intel>	the file handling stuff
 154 17:42:04 <Jason_at_Intel>	I think what i have in Parts for override the file open call ( and unlink .. minus maybe the readonly file issue)  is ready to go
 155 17:42:40 <Jason_at_Intel>	I have it re factored in truck as a separate file
 156 17:42:54 <Jason_at_Intel>	to make it easy to add to SCons
 157 17:43:24 <Jason_at_Intel>	there is a little quirk in that I whack the current SCons win32 file overrides
 158 17:43:33 <Jason_at_Intel>	but other than that I think this code is done
 159 17:44:12 <Jason_at_Intel>	I am sure there is other stuff.. but i can remember the e-mails at this time ( long day...)
 160 17:44:18 <sgk>	well, if your overrides work better, that should be fine
 161 17:44:49 <sgk>	i hear you re: long day, real life's been impossible lately
 162 17:45:24 <sgk>	there's nothing in your windows symlink support that'll blow up on earlier Windows or Python versions, is there?
 163 17:46:48 <Jason_at_Intel>	only if you don't have ctypes
 164 17:47:10 <Jason_at_Intel>	I have fixes in my CCopy builder to deal with an issue with hardlinks already existing
 165 17:47:37 <Jason_at_Intel>	might be a better way minus the delete call to deal with it... but it works well enough
 166 17:47:54 <sgk>	okay, so send me a patch and I'll take a look
 167 17:48:00 <Jason_at_Intel>	however that code.. or any code like this needs this override to allow correct file creation so links of some form can be used
 168 17:48:04 <sgk>	and I'll also dig up the email stuff I was supposed to send
 169 17:48:21 <Jason_at_Intel>	so.. that is the question.. I have a file
 170 17:48:25 <Jason_at_Intel>	not a patch
 171 17:49:08 <Jason_at_Intel>	http://parts.tigris.org/source/browse/parts/trunk/parts/parts/overrides/os_file.py?revision=344&view=markup
 172 17:50:02 <Jason_at_Intel>	sort of unclear how to do this "patch" in Scons as it is new code, and might need a certain location
 173 17:51:20 <Jason_at_Intel>	so i guess look it over.. I will send links again tomorrow in e-mail
 174 17:51:49 <Jason_at_Intel>	we can discuss where it should go in SCons
 175 17:53:06 <Jason_at_Intel>	Does that sound OK?
 176 17:55:04 <Jason_at_Intel>	??
 177 17:55:21 <sgk>	sure, sounds good
 178 17:55:29 <sgk>	(sorry, got interrupted -- still at work)
 179 17:55:36 <Jason_at_Intel>	great
 180 17:55:51 <Jason_at_Intel>	oh I recall one item
 181 17:55:56 <Jason_at_Intel>	the scons.bat issue
 182 17:56:06 <Jason_at_Intel>	you can use scons.py on windows
 183 17:56:15 <Jason_at_Intel>	it works better in general
 184 17:56:36 <Jason_at_Intel>	but we can do that in e-mail
 185 17:56:47 <sgk>	except for passing command line arguments, there's some gotcha with that
 186 17:57:07 <Jason_at_Intel>	I have to get going here it is about 8pm.. need to help with the twins...
 187 17:57:08 <sgk>	at least for some combination of Python version + Windows version
 188 17:57:09 <Jason_at_Intel>	oh??
 189 17:57:19 <Jason_at_Intel>	I have not seen this
 190 17:57:34 <sgk>	yeah, i remember having some links describing it, i'll dig them up
 191 17:57:49 <Jason_at_Intel>	ok.. will be good to review
 192 17:58:01 <sgk>	yeah
 193 17:58:09 <sgk>	okay, good night, good luck with the twins
 194 17:58:29 <Jason_at_Intel>	thank..
 195 17:58:37 <Jason_at_Intel>	good night!
 196 17:58:44 *	Jason_at_Intel has quit (Quit: ChatZilla 0.9.86 [Firefox 3.5.3/20090824101458])
 197 18:00:07 *	bdbaddog (~bdeegan@adsl-71-131-1-95.dsl.sntc01.pacbell.net) has left #SCONS
 198 18:00:13 *	sgk (~sgk@nat/google/x-mbowtfhelsfesqin) has left #SCONS
 199 

BugParty/IrcLog2010-10-26 (last edited 2010-11-15 02:31:36 by ip68-7-79-188)