Anthony Baxter wrote: > Because the Python.asdl and the generated Python-ast.[ch] get checked > into svn in the same revision, the svn export I use to build the > tarballs sets them all to the same timestamp on disk (the timestamp > of the checkin).
Actually, the generated c file often has a newer checkin, because it gets the version of Python.asdl embedded - but only after Python.asdl gets its $Revision$ updated (i.e. after the checkin). Still, the .h file will have the same revision, or even an older one if the AST change doesn't affect the header file (not sure if this can ever happen). > To "fix" this, I'm going to make the "welease" script that does the > releases touch the ast files to set their timestamps newer than that > of Python.asdl. It's not an ideal solution, but it should fix the > problem. The other option would be some special Makefile magic that > detects this case and doesn't rebuild the files if no "python" binary > can be found. I have no idea how you'd do this in a portable way. The common approach would be to use autoconf for that. Let autoconf search for a Python binary, and fall back to /bin/true if you don't find any. > Anyone got other options? This strategy (of specifically touching the files for the release) is quite common. Alternatively, you could also force a commit for Python-ast.[ch] if they have the same revision as the .asdl file. As the AST doesn't change that often, this dummy commit would only be rarely needed (and, as I suggested, only on the .h file). 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
