On Wed, Dec 5, 2012 at 9:17 AM, Larry Hastings <la...@hastings.org> wrote: > Here's my blue-sky probably-overengineered proposal: we (and when I say "we" > I mean "I") write a cross-platform C program that could be harmlessly but > usefully integrated into the build process. First, we add a checksum for > the *input* into the Clinic output. Next, when you run this program, you > give it a C file as an argument. First it tries to find a working Python on > your path. If it finds one, it uses that Python to run Clinic on the file, > propagating any error code outward. If it doesn't find one, it understands > enough of the Clinic format to scan the C file looking for Clinic blocks. > If it finds one where the checksum doesn't match (for input or output!) it > complains loudly and exits with an error code, hopefully bringing the build > to a screeching halt. This would integrate Clinic into the build process > without making the build reliant on having a Python interpreter available.
That would probably work, but it implies having two places that understand Clinic blocks (the main Python script, and the C binary), with the potential for one of them to have a bug. Is it possible, instead, to divide the build process in half, and actually use the newly-built Python to run all Clinic code? That would put some (maybe a lot of) restrictions on what functionality the Clinic parser is allowed to use, but if it can work, it'd be clean. (The main code of Clinic could still demand a fully-working Python if that's easier; I'm just suggesting making the "check the checksums" part of the same Python script as does the real work.) ChrisA _______________________________________________ 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
