URL:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=17230>
Summary: Leading ./ is stripped from targets and
prerequisites
Project: make
Submitted by: None
Submitted on: Saturday 07/29/2006 at 00:59 UTC
Severity: 3 - Normal
Item Group: Bug
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Component Version: 3.79.1
Operating System: Any
Fixed Release: None
_______________________________________________________
Details:
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 [EMAIL PROTECTED]
(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.)
_______________________________________________________
File Attachments:
-------------------------------------------------------
Date: Saturday 07/29/2006 at 00:59 UTC Name: Makefile Size: 401B By: None
Makefile
<http://savannah.gnu.org/bugs/download.php?file_id=10437>
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=17230>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
