[Python-Dev] The Return Of Argument Clinic

[Brett Cannon]

On Tue, Aug 6, 2013 at 12:59 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 6 August 2013 09:53, Larry Hastings <larry at hastings.org> wrote:
> > On 08/05/2013 02:55 AM, Nick Coghlan wrote:
> > On 5 August 2013 18:48, Larry Hastings <larry at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130806/92cea5a3/attachment.html>