This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: the first build after a change to Makefile.pre.in uses the old Makefile
Type: behavior Stage: resolved
Components: Build Versions: Python 3.7, Python 3.6, Python 2.7
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: xdegaye
Priority: normal Keywords: patch

Created on 2017-12-31 07:53 by xdegaye, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
Makefile.pre.in.diff xdegaye, 2017-12-31 07:53
stale-makefile.patch xdegaye, 2018-01-03 11:29
Messages (3)
msg309270 - (view) Author: Xavier de Gaye (xdegaye) * (Python triager) Date: 2017-12-31 07:53
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'").
msg309377 - (view) Author: Xavier de Gaye (xdegaye) * (Python triager) Date: 2018-01-02 15:28
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".
msg309409 - (view) Author: Xavier de Gaye (xdegaye) * (Python triager) Date: 2018-01-03 11:29
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:56adminsetgithub: 76642
2019-12-10 08:11:17xdegayesetstatus: open -> closed
resolution: not a bug
stage: needs patch -> resolved
2018-01-03 11:29:41xdegayesetfiles: + stale-makefile.patch

messages: + msg309409
2018-01-02 15:28:28xdegayesetmessages: + msg309377
2017-12-31 07:53:32xdegayecreate