bugmake - Bugs: bug #24487, "foo" should not be...


bug #24487: "foo" should not be identified with "./foo" if foo is phony

Submitter:  Stepan Kasal <kasal>
Submitted:  Wed 08 Oct 2008 05:34:14 PM UTC
Severity:  3 - Normal Item Group:  Bug
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Open
Component Version:  3.82 Operating System:  Any
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:
       No canned response available


Mon 02 Jan 2017 09:22:02 PM UTC, comment #4: 

The documentation for .PHONY states ( https://www.gnu.org/software/make/manual/html_node/Phony-Targets.html ):

The implicit rule search (see Implicit Rules) is skipped for .PHONY targets. This is why declaring a target as .PHONY is good for performance, even if you are not worried about the actual file existing.

This explains all the later commentary regarding declaring targets that match pattern rules to be phony... that's documented, expected behavior and a fundamental feature of using .PHONY.

If you want to force a target to always be rebuilt via a pattern rule, you should use the force target method as described: https://www.gnu.org/software/make/manual/html_node/Force-Targets.html

However, I want to say that creating match-anything patterns as shown in the comments below is generally not a good idea: it often causes performance issues.

The original question, which is not related to any of these other comments, still remains.

Paul D. Smith <psmith>
Project Administrator
Fri 30 Sep 2016 01:31:47 PM UTC, comment #3: 

This problem is now worse because it is not allowed to mix implicit and normal rules:

$ cat Makefile
% build:
        echo $@

.PHONY: build
$ make build
Makefile:1: *** mixed implicit and normal rules.  Stop.

So now one is forced to declare the targets multiple times.

Felipe Sateler <fsateler>
Mon 10 Oct 2011 12:35:37 PM UTC, comment #2: 

I noticed the same problem with

.PHONY: %.e


-> make: Nothing to be done for ´target´.

I would be terribly happy if you guys could fix that.

Mon 12 Sep 2011 09:48:17 AM UTC, comment #1: 

Is this perhaps the bug that causes the problems discussed at


Quoting here so that you don't need to browse off-site:

    .PHONY: build
            dh $@

What do you think happens when you run debian/rules build in a directory containing a build file or directory?

    make: Nothing to be done for `build’.

However, an explicit rule, like the following, works:

    .PHONY: build
            dh $@

It happens that many of the packages I maintain contain a build subdirectory in their source. As such, to work around the aforementioned issue, I just declared the dh rules explicitely, as in:

    .PHONY: build binary binary-arch binary-indep (...)
    build binary binary-arch binary-indep (...):
            dh $@

And this obviously doesn’t scale for new rules such as build-arch and build-indep.

Timo Lindfors <lindi>
Wed 08 Oct 2008 05:34:14 PM UTC, original submission:  

The target "./foo" is usually the same as "foo", since the file is the same.

But is this necessary also for phony targets?

(This issue was noticed when a make compiled with --enable-case-insensitive-file-system confused the phony target "install" with the rules for file "INSTALL".)

Stepan Kasal <kasal>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by fsateler (Posted a comment)
  • -email is unavailable- added by psmith (Updated the item)
  • -email is unavailable- added by lindi (Posted a comment)
  • -email is unavailable- added by kasal (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.





    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-10-09 psmith Component Version4.0 3.82

    Back to the top

    Powered by Savane 3.9