Am 31.08.12 15:19, schrieb Trent Nelson:> I think I should clarify my use case that resulted in raising this> bug.>> 1. Create a fresh hg clone, say, ~/hg/cpython-3.2.> 2. Make it readonlyThe use case is really uncontended, and long-standing. People wantto build from CD-ROM sources, from sources mounted via NFS,from sources owned by some other user - there are really manyreasons why you want to build in a separate directory, and whyyou then do not want the original source be clobbered.> Richard: what was your use case?I guess pretty much the same (though perhaps not ZFS).> What steps did you take that> resulted in getting typeslots.inc and _sysconfigdata.py written to?TouchInclude/typeslots.h (before making the checkout readonly)to see this problem. On a hg checkout, it really depends on the orderin which Mercurial creates the files to either run or not run into oneof these issues.You were lucky that the timestamps happened to be in an order werein an order that caused typeslots.inc to be newer than its sources.AFAIK, hg uses alphapbetical order when updating files, so this mayhave helped.> I think I'm +1 on reverting and trying the '-' approach originally> used by Neil.Please don't. I think Victor dropped the - because it would maskerrors from running pgen. pgen might fail, but pgen.stamp is stillgenerated. Then, on a subsequent run, pgen would not run again.Of course, pgen.stamp is a later addition (by me), so this wasn'toriginally a problem.I think the regular case should be that the time stamps are inthe right order in the source tree, so none of the generatorsshould run. But if they happen to be in the wrong order (eitherbecause of Mercurial, or because one of the sources was actuallymodified), then the generators should run and output into thebuild directory.Since the committed patch is already a step in that direction,I think it now needs to be completed. It's mandatory (IMO)that the generated files are actually used; that the generatorsare not run if not needed is optional and can be fixed later.