On 15 March 2016 at 15:15, Martin Panter <vadmium...@gmail.com> wrote:
> The problem is not the reference to Makefile. The graminit files do
> not depend on Makefile. The bigger problem is that the checked-in
> files depend on compiled programs. This is a summary of the current
> rules for importlib:
> _freeze_importlib.o: _freeze_importlib.c Makefile
> _freeze_importlib: _freeze_importlib.o [. . .]
>         $(LINKCC) [. . .]
> importlib_external.h: _bootstrap_external.py _freeze_importlib
>         _freeze_importlib _bootstrap_external.py importlib_external.h
> importlib.h: _bootstrap.py _freeze_importlib
>         _freeze_importlib _bootstrap.py importlib.h
> So importlib.h depends on the _freeze_importlib compiled program (and
> only indirectly on Makefile). The makefile says we have to compile
> _freeze_importlib before checking if importlib.h is up to date.

Ah, I understand now - the fundamental problem is with a checked in
file depending on a non-checked-in file, so if you clean out all the
native build artifacts when cross-compiling, the makefile will attempt
to create target versions of all the helper utilities (pgen,
_freeze_importlib, argument clinic, etc).

Would it help to have a "make bootstrap" target that touched all the
checked in generated files with build dependencies on non-checked-in
files, but only after first touching the expected locations of the
built binaries they depend on?


Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
Python-Dev mailing list

Reply via email to