I have a makefile compiling a C/C++ project. The final linker line was too many characters for the shell, so I switched to using an argument list file passed to the linker as suggested in the following question: Argument list too long when linking with GNU Make
I now have this rule:
$(OBJECT_LIST): $(OBJECT_FILES)
$(file > $@,$^)
Where OBJECT_LIST is the path to the file containing the list of objects and OBJECT_FILES is the list of object files that would have been passed directly to the linker.
My IDE uses the --just-print option to determine which files it should index. When it executes the above rule, it throws and error similar to the following:
open: objects.in: No such file or directory. Stop.
Since this was a dry run (from the just-print option), obviously none of the directories were actually created, so why is make still attempting to execute the file function? What can I do to fix this problem?
Even if you run with --just-print, make still has to expand the recipe else how can it print out what would be run? When the recipe is expanded all make variables and functions are expanded.
Until after the expansion happens make can't even know for sure whether or not it should run the recipe, since it could be prefixed with a +:
FOO = +echo do this
foo:
$(FOO)
I know of no way to solve this problem, except force the directories that are needed for this $(file ...) to be created even when -n is provided. For example:
$(OBJECT_LIST): $(OBJECT_FILES)
$(shell mkdir -p '$(@D)')
$(file > $@,$^)
A rare reason you need to use $(shell ...) within a recipe. Alternatively if you have other rules that create the directory you can prefix their recipe lines with + to force them to run even with -n.