Today when I built my project with the –debug=v I noticed something that I don’t really understand what it means.
Right at the top where he includes the “sub makefiles” there is a strange printout that tells me (search path) (no ~ expansion)… What does this mean?
The printout looks like this:
Reading makefiles...
Reading makefile `Makefile'...
Reading makefile `make_pc.mk' (search path) (no ~ expansion)...
Reading makefile `print_ring/make.mk' (search path) (no ~ expansion)...
Reading makefile `vendor/unity/make.mk' (search path) (no ~ expansion)...
Reading makefile `test01/make.mk' (search path) (no ~ expansion)...
The line in the main Makefile that is using include looks like this:
TEST := test01
include $(TEST)/make.mk
And a included makefile could look like this:
CFLAGS += -Itest01/
OBJ += test_main.o
test_main.o: test01/test_main.c
@ echo ".compiling"
$(CC) $(CFLAGS) -o $@ $<
Is there a better way to play with the search paths? But would ~ expand to my unix user home dir?
Note: I am doing this on a Linux (Ubuntu) machine.
Note: All the files can be found at in this github project.
/Thanks
Some of this information is aimed at people debugging Make itself rather than debugging the build infrastructure of their own projects, so it’s not too surprising if it’s not really documented or of particular use for tracking down your own build problems.
That said, you can figure out what these mean by spending a few minutes with the GNU Make source code.
(search path) is Make’s internal
RM_INCLUDEDflag, which (I’m oversummarizing) means this makefile was encountered viaincludewithin another makefile and the-Isearch path may have been examined to find it.(no ~ expansion) is its internal
RM_NO_TILDEflag and is explained in this comment in Make’s read.c:GNU Make does indeed expand ~ to home directories, and this flag stops it from happening twice — which I suppose could make a difference on some very unusual file system layouts.