Brett Cannon wrote:
> What do other people think of this option? Sounds reasonable to me.
> if people like it I will add this to the suggested config options
> specified in the dev FAQ.
There is a problem with that option, an no good solution. If you
had built the tree before the update, the object files will have
changed recently. If you then update with use-commit-times, some
files might get changes so they are newer than they used to be,
but still older than their object files.
As a result, a rebuilt will fail to pick up the modified sources,
potentially resulting in a broken interpreter (e.g. when a structure
layout changed, yet this change didn't get compiled into all
object files).
CVS tried to tackle this problem with this approach: on update,
touch the updated files so that they are all new, but have the
same relative order in time as the commit times (e.g. spacing
them apart by one second).
Of course, with subversion changesets, this is futile: the
generated files will be in the same changeset as the sources
(e.g. Python-ast committed together with .asdl, configure
committed together with configure.in). As it is the changeset
which has the commit time, all these files have the *same*
commit time. make(1) then decides "not newer".
The common solution is to have an application-specific update
procedure. For example, we might provide a
make update
target, which is defined as
update:
svn update
sleep 1
test ! Python/Python-ast.c -nt Parser/Python.asdl && \
touch Python/Python-ast.c
test ! Include/Python-ast.h -nt Parser/Python.asdl && \
touch Include/Python-ast.h
test ! configure -nt configure.in && \
touch configure
This, of course, assumes that the committers of these files
always regenerated them properly before committing.
See
http://gcc.gnu.org/viewcvs/trunk/contrib/gcc_update?rev=106327&view=markup
for gcc's solution to this problem; gcc developers are
expected to invoke contrib/gcc_update, which will automatically
spread the right time stamps after the update completed.
Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
