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 Oct 8 17:34:14 2008  
 
Severity: 3 - NormalItem Group: Bug
Status: NonePrivacy: Public
Assigned to: NoneOpen/Closed: Open
Component Version: 3.82Operating System: Any
Fixed Release: NoneTriage Status: None

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

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

 

Mon Jan 2 21:22:02 2017, 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 Sep 30 13:31:47 2016, 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 Oct 10 12:35:37 2011, 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 Sep 12 09:48:17 2011, 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 Oct 8 17:34:14 2008, 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 File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

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

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follows 1 latest change.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed Oct 9 05:03:40 2013psmithComponent Version4.0=>3.82

    Back to the top


    Powered by Savane 3.1-cleanup