On Mon, 14 Mar 2016 03:04:08 -0000, "Gregory P. Smith" <g...@krypto.org> wrote: > On Sun, Mar 13, 2016 at 7:41 PM Martin Panter <vadmium...@gmail.com> wrote: > > > On 13 March 2016 at 01:13, Russell Keith-Magee <russ...@keith-magee.com> > > wrote: > > > The patches that I've uploaded to Issue23670  show a full > > cross-platform > > >  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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com