After applying the attached Makefile.pre.in.diff that changes the text of the message printed by the 'Makefile' target, the make command gives: $ make CONFIG_FILES=Makefile.pre CONFIG_HEADERS= /bin/sh config.status config.status: creating Makefile.pre make -f Makefile.pre Makefile make[1]: Entering directory '/path/to/master' /bin/sh ./Modules/makesetup -c ./Modules/config.c.in \ -s Modules \ Modules/Setup.local \ Modules/Setup This is the new Makefile. The Makefile was updated, you may need to re-run make. <--- new Makefile make[1]: Leaving directory '/path/to/master' /bin/sh ./Modules/makesetup -c ./Modules/config.c.in \ -s Modules \ Modules/Setup.local \ Modules/Setup The Makefile was updated, you may need to re-run make. <--- old Makefile gcc -pthread -c -Wno-unused-result -Wsign-compare -g -Og -Wall -Wstrict-prototypes -std=c99 -Wext ra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-functio n-declaration -I. -I./Include -DPy_BUILD_CORE \ -DABIFLAGS='"dm"' \ -DMULTIARCH=\"x86_64-linux-gnu\" \ -o Python/sysmodule.o ./Python/sysmodule.c .... The two messages printed by the 'Makefile' target show that make is still running the previous Makefile after completing the sub-make (i.e. after the line "make[1]: Leaving directory '/path/to/master'").
Hum, GNU make does re-execute the updated Makefile [1] after the 'Makefile' target has been remade. The problem occurs though with the other make variants that do not have this feature. [1] This may be shown by updating Makefile.pre.in and adding an 'echo' recipe in the 'Python/sysmodule.o' target for example, or by running 'make -d' after Makefile.pre.in has been modified and confirming that the command prints "Re-executing[1]: make -d".
Two problems: * It is not clear whether one should re-run make after the Makefile file has been updated since the (stale when not using GNU make) Makefile is run to completion. * The 'Makefile' target is remade twice when Makefile.pre.in has been changed. The 'Makefile.pre' target is a pre-requisite of only the 'Makefile' target which means that if 'Makefile.pre' is being remade then 'Makefile' will be remade next and so it is useless to run the 'Makefile' target in a sub-make within the 'Makefile.pre' target. The implementation of the uploaded stale-makefile.patch aborts the build when 'Makefile' has been remade and we are not running GNU make. It also removes the useless sub-make in the 'Makefile.pre' target.
History
Date
User
Action
Args
2022-04-11 14:58:56
admin
set
github: 76642
2019-12-10 08:11:17
xdegaye
set
status: open -> closedresolution: not a bugstage: needs patch -> resolved
