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? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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