On Tue, Aug 6, 2013 at 12:59 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 6 August 2013 09:53, Larry Hastings <la...@hastings.org> wrote: > > On 08/05/2013 02:55 AM, Nick Coghlan wrote: > > On 5 August 2013 18:48, Larry Hastings <la...@hastings.org> wrote: > > > > Question 0: How should we integrate Clinic into the build process? > > > > Isn't solving the bootstrapping problem the reason for checking in the > > clinic-generated output? If there's no Python available, we build what > > we have (without the clinic step), then we build it again *with* the > > clinic step. > > > > It solves the bootstrapping problem, but that's not the only problem > Clinic > > presents to the development workflow. > > > > If you modify some Clinic DSL in a C file in the CPython tree, then run > > "make", should the Makefile re-run Clinic over that file? If you say > "no", > > then there's no problem. If you say "yes", then we have the problem I > > described. > > Ah, I think I see the problem you mean. What is defined in the > makefile as the way to regenerate an object file from the C file. If > it is run clinic and then run the compiler, then you will get a > dependency loop. If it doesn't implicitly run clinic, then we risk > checking in inconsistent clinic metadata. > > I think the simplest answer may be to have "make clinic" as an > explicit command, along with a commit hook that checks for clinic > metadata consistency. Then "make" doesn't have to change and there's > no nasty bootstrapping problem. Can't we just do what we already do for the generated AST code or what we used to do for importlib's frozen code; we have the touch extension for hg integration for this kind of issue.
_______________________________________________ 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
