Sat 29 Jul 2006 12:59:56 AM UTC, original submission:
Below is a stripped-down version of a much more complicated makefile.
Several %.r files are targets. Each %.r goes into one directory called
$(RES_DIR), and depends on a %.exe of the same name in another
directory, called $(EXE_DIR).
The %.exe are intermediate targets. Normally they are generated by
compiling, and have a pattern as a prerequisite too, but for these
purposes, no prerequisite is necessary, and we'll just create a shell
script executable.
The problem: If the %.exe files are explicitly listed as coming from
./ (the working directory), the ./ is stripped from the targets and
prerequisites.
That is, if $(EXE_DIR) is . then $(EXE_DIR)/ is not left intact in
$@ and $<.
This occurs in three contexts in which the ./%.exe pattern is used
below: When the ./%.exe is a target, when the ./%.exe is a
prerequisite, and when the pattern is used to declare the %.exe
targets as immediate:
# make
$(EXES) = ./a.exe ./b.exe GOOD
echo "echo I hope . is in your path" > a.exe Should be ./a.exe
chmod a+x a.exe Should be ./a.exe
a.exe Should be ./a.exe
I hope . is in your path
$(EXES) = ./a.exe ./b.exe GOOD
echo "echo I hope . is in your path" > b.exe Should be ./b.exe
chmod a+x b.exe Should be ./b.exe
b.exe Should be ./b.exe
I hope . is in your path
rm a.exe b.exe Consistent
If . is not in your PATH, then this error occurs:
# make
$(EXES) = ./a.exe ./b.exe
echo "echo I hope . is in your path" > a.exe
chmod a+x a.exe
a.exe Should be ./a.exe - FATAL
make: a.exe: Command not found
make: *** [results/a.r] Error 127
rm a.exe
The problem is the same whether ordinary rules, pattern rules, or
static rules are used.
There are workarounds, such as adding . to your PATH (insecure!),
explictly using ./$< instead of $< (won't work if EXE_DIR is changed
to an absolute path), etc. But none of these should be necessary,
because the explicit ./%.exe pattern should have remained intact.
For the purposes of comparing whether two targets or prerequisites
are the same name, leading ./'s should be ignored. But leading ./'s
should be kept intact in automatic variable expansions such as $<
and $@.
(Bugs 10708 and 15338 are the same thing. This is just another example
showing how it can fatally ruin a project -- a make "project", that is.)
|