[Python-Dev] "make touch" replaced with "make regen-all"

Nick Coghlan ncoghlan at gmail.com
Fri May 5 02:39:17 EDT 2017


On 5 May 2017 at 16:01, Victor Stinner <victor.stinner at gmail.com> wrote:
> Le 5 mai 2017 6:31 AM, "Nick Coghlan" <ncoghlan at gmail.com> a écrit :
>
> The note just needs to say that folks that care about doing "complete"
> builds need to adjust their command sequence to be "./configure
> <options> && make regen-all && make install", rather than the previous
> pattern of "./configure <options> && make install".
>
>
> Hum, you only need to regenerate files if you modify Grammar, AST or
> opcodes. Do you mean that Linux distro make such downstream changes?

No, but at least some of them do have a policy that it be possible to
rebuild the project from its "original sources" in the distro's build
system without relying on cached artifacts provided by the upstream
project. In CPython's case, that means distros with such a policy
should ensure they're running the "regen-all" step in addition to the
C build steps.

To be 100% clear, I agree it makes sense to change the default
behaviour to be to re-use our checked in generated files, and to make
that policy consistent across all active branches.

The request for a note is just to make it clear to redistributors that
CPython now has two potential tiers of build dependencies (those
required to run "make" and those required to run "make regen-all"), so
if a redistributor cares about that kind of thing, they're going to
have to update their build processes accordingly. If they don't make
they change, they may inadvertently lose the ability to run the
"regen-all" step at some point in the future (as an extreme example:
to avoid a tricky bootstrapping problem, while still improving the
tools available for standard library maintenance, we may someday
decide to allow cffi and/or cython as file regeneration dependencies,
while continuing to disallow them as conventional build dependencies).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-Dev mailing list