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

 
 

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

Submitted by:  Stepan Kasal <kasal>
Submitted on:  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

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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

%.e:
DO_SOMETHING

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

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

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

Is this perhaps the bug that causes the problems discussed at

http://glandium.org/blog/?p=2126

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
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:
   
   
Comment:
   

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)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    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.3