Some intermediate files will be automatically deleted when make is completed.

question

Run make and some .o files will be automatically deleted when it is nearly completed.

investigation

Add the command line option "--debug=basic", and the output of make ends with:

Must remake target 'all'.
Successfully remade target file 'all'.
Removing intermediate files...
rm AnalyseAllPlaysBin.o AnalysePlayBin.o hands.o AnalyseAllPlaysPBN.o AnalysePlayPBN.o

The penultimate line prompts that these .o files are automatically deleted by make because they are intermediate files .

Generally, the exe file generated in the Makefile is similar to the following writing:

$(GAMEDIR)/NetHackW.exe: $(NHWOBJS) $(NHWRES) $(LUALIB) | $(GAMEDIR)
	$(ld) $(LDFLAGS) -mwindows $^ $(LIBS) -static -lstdc++ -o$@

The exe file name and object file name do not use wildcards (%).

The problem occurs because multiple exe files need to be generated. The Makefile is as follows:

all: $(EXE_FILES)

%.exe: $(OBJ_FILES) %.o
	$(CC) $^ $(LDFLAGS) $(LDLIBS) -o $@

%.o: %.cpp
	$(CC) $(CXXFLAGS) -c $<

So I searched for "intermediate files" in the "Gnu Make" manual, and sure enough I found relevant instructions in 10.4 Chains of Implicit Rules
, to the effect of: "If the intermediate file is no longer needed, make will delete it. So an intermediate file The file does not exist before make is run or after make is run. Make prints a 'rm -f' command when reporting deletion to you, indicating that a file was deleted." I didn't see "-f", maybe the version is different
. .

Solution

Follow the instructions in the manual to add the .PRECIOUS target and use these .o files as its prerequisites, and the problem will be solved.

Extra

There are other .o files in the Makefile that have not been automatically deleted. After checking, I found the difference. It has an extra line:

CalcDDtable.o: ../include/dll.h hands.h

Because this .o file clearly appears in the dependency rules without wildcards (%), it was not deleted as an intermediate file by make in the end. Effective but not very elegant (.o's dependence on the header files included in cpp is another topic).