This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author loewis
Recipients loewis, ned.deily, petri.lehtinen, python-dev, sbt, trent
Date 2012-08-31.13:56:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <5040C28C.9060300@v.loewis.de>
In-reply-to <1346419149.67.0.667858316622.issue15819@psf.upfronthosting.co.za>
Content
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 readonly

The use case is really uncontended, and long-standing. People want
to build from CD-ROM sources, from sources mounted via NFS,
from sources owned by some other user - there are really many
reasons why you want to build in a separate directory, and why
you 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?

Touch Include/typeslots.h (before making the checkout readonly)
to see this problem. On a hg checkout, it really depends on the order
in which Mercurial creates the files to either run or not run into one
of these issues.

You were lucky that the timestamps happened to be in an order were
in an order that caused typeslots.inc to be newer than its sources.
AFAIK, hg uses alphapbetical order when updating files, so this may
have 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 mask
errors from running pgen. pgen might fail, but pgen.stamp is still
generated. Then, on a subsequent run, pgen would not run again.
Of course, pgen.stamp is a later addition (by me), so this wasn't
originally a problem.

I think the regular case should be that the time stamps are in
the right order in the source tree, so none of the generators
should run. But if they happen to be in the wrong order (either
because of Mercurial, or because one of the sources was actually
modified), then the generators should run and output into the
build 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 generators
are not run if not needed is optional and can be fixed later.
History
Date User Action Args
2012-08-31 13:56:31loewissetrecipients: + loewis, ned.deily, trent, python-dev, sbt, petri.lehtinen
2012-08-31 13:56:30loewislinkissue15819 messages
2012-08-31 13:56:30loewiscreate