bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #17230] Leading ./ is stripped from targets and prerequisites


From: anonymous
Subject: [bug #17230] Leading ./ is stripped from targets and prerequisites
Date: Sat, 29 Jul 2006 00:59:57 +0000
User-agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20021203

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 address@hidden

(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/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]