[Python-Dev] Bug in build system for cross-platform builds

[R. David Murray]

On Mon, 14 Mar 2016 03:04:08 -0000, "Gregory P. Smith" <greg at krypto.org> wrote:
> On Sun, Mar 13, 2016 at 7:41 PM Martin Panter <vadmium+py at gmail.com> wrote:
> 
> > On 13 March 2016 at 01:13, Russell Keith-Magee <russell at keith-magee.com>
> > wrote:
> > > The patches that I've uploaded to Issue23670 [1] show a full
> > cross-platform
> > > [1] http://bugs.python.org/issue23670
> > > build process. After you apply that patch, the iOS directory contains a
> > > meta-Makefile that manages the build process.
> >
> > Thanks very much for pointing that out. This has helped me understand
> > a lot more things. Only now do I realize that the four files generated
> > by pgen and _freeze_importlib are actually already committed into the
> > Mercurial repository:
> >
> > Include/graminit.h
> > Python/graminit.c
> > Python/importlib.h
> > Python/importlib_external.h
> >
> > A question for other Python developers: Why are these generated files
> > stored in the repository? The graminit ones seem to have been there
> > since forever (1990). It seems the importlib ones were there due to a
> > bootstrapping problem, but now that is solved. Antoine
> > <https://bugs.python.org/issue14928#msg163048> said he kept them in
> > the repository on purpose, but I want to know why.
> >
> > If we ignore the cross compiling use case, would there be any other
> > consequences of removing these generated files from the repository?
> > E.g. would it affect the Windows build process?
> >
> > I have two possible solutions in mind: either remove the generated
> > files from the repository and always build them, or keep them but do
> > not automatically regenerate them every build. Since they are
> > generated files, not source files, I would prefer to remove them, but
> > I want to know the consequences first.
> >
> 
> They should not be regenerated every build, if they are, that seems like a
> bug in the makefile to me (or else the timestamp checks that make does vs
> how your code checkout happened).  Having them checked in is convenient for
> cross builds as it is one less thing that needs a build-host-arch build.

The repo-timestamp problem is addressed by the 'make touch' target.

And yes, checking in these platform-independent artifacts is very
intentional: less to build, fewer external dependencies in the build
process...you don't need to *have* python to *build* python, which you
would have to if they were not checked in.

--David