NetBSD-Bugs archive

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

Re: bin/43502: make failes to stip suffix if target is phony

The following reply was made to PR bin/43502; it has been noted by GNATS.

From: Wolfgang Stukenbrock <>
Subject: Re: bin/43502: make failes to stip suffix if target is phony
Date: Mon, 28 Jun 2010 11:44:21 +0200

 Can you please add me to the email-list in the new report.
 Thanks in advance.
 (Or at least send me the problem number, so I can track it myself.)
 If $* gets filled as expected (and documented) in the future this is of 
 interest for me.
 One very bad thing with make programs in general are, that they are all 
 incompartible to each other as soon as you start to use any of the more 
 high-level things in them.
 And there are not only general the syntax problems with differences in 
 key-words, variable subtition, sets of automatic variables, ...
 And if you try to have a protable version, you always have to enshure 
 that a specific make-variant is installed, because there is no common 
 make available on "all" systems (commertial, open-source).
 And the subset of functionality for all make version is poor and not 
 realy usable.
 The main reason why I've tagged the virtual targets .tg and .ttg as 
 PHONY is that they will never (or may not) exist in the filesystem and 
 make should not try to search for them. Normaly PHONY does it in the 
 expectec way, if a make program supports PHONY at all.
 The names are variants of main targets of the makefile and this makefile 
 should call some kind of sub-makes in sets of subdirectories to do the 
 main things. (Of cause removed from the makefile in the report in order 
 to keep it as small as possible.)
 This time I don't want to specify all possible targets of the sub-makes 
 in the top-level makefile as done before in order to reduce the required 
 work on toplevel if new targets are added or the rules themself gets 
 I need to specify some common dependencies that are placed in the 
 virtual rules. It has been a nice way to use these kind of derived 
 targets in the past.
 Even if I use a for-loop (and that is one of the non-portable syntax 
 parts ...), I need to specify all target names and the advantage of the 
 pattern is lost.
 If the bmake family is designed to mix the pattern matching (or 
 construction) on the internal strings with the filesystem-search while 
 ignoreing other hint information from the makefile (as PHONY), it is OK 
 for me - but a hint in the man-page would have been nice.
 I think theese two things should be treeted completly independent from 
 each other, but that is my oppion and other people may see it in a 
 different way.
 Best reguards
 W. Stukenbrock
 David Holland wrote:
 > The following reply was made to PR bin/43502; it has been noted by GNATS.
 > From: David Holland <>
 > To:
 > Cc: 
 > Subject: Re: bin/43502: make failes to stip suffix if target is phony
 > Date: Sun, 27 Jun 2010 00:55:11 +0000
 >  On Thu, Jun 24, 2010 at 10:15:01AM +0000, 
 > wrote:
 >   > The following makefile fails to do the rigth thing - at least
 >   > from my understanding of make.
 >   > [...]
 >   >  
 >   > The problem seems to be, that if a target is marked PHONY the
 >   > suffix detection stuff in make does not work anymore.
 >  Since suffix rules are based on matching against things that exist,
 >  I'm surprised this works even halfway. I would expect it to not find
 >  the PHONY .tg rules as valid sources for the suffix rule; but
 >  apparently it does.
 >  Note though that line 2412 of suff.c says
 >      * If this is a .PHONY target, we do not apply suffix rules.
 >  so the behavior you're seeing is apparently intentional, though
 >  underdocumented.
 >  That said, I would advise against relying on the detailed behavior of
 >  suffix rules because it isn't very portable. gmake, for example, does
 >  not exhibit the same behavior on your makefile. (Arguably it is even
 >  less useful in that it silently skips t4.) I don't have ready access
 >  to any of the various vendor variants of legacy System V make to test
 >  any more, but I wouldn't be surprised if those also did one or more
 >  different things.
 >  I'm finding it hard to guess what you're trying to really do that this
 >  is a simplified fragment of; but my guess is that you're better off
 >  approaching it some other way. Usually if you can afford to be
 >  bmake-specific, explicit rules defined with .for loops are the best
 >  way to tackle these sorts of issues. If you can't, it gets murkier.
 >  The fact that $* is not defined for t2 appears to be a legitimate bug;
 >  it seems to arise for all .PHONY targets. It's also not so obvious how
 >  to fix it. In order to avoid confusion I think I'm going to open a new
 >  PR for that.
 >  -- 
 >  David A. Holland

Home | Main Index | Thread Index | Old Index