The following reply was made to PR bin/43502; it has been noted by GNATS.
From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc:
Subject: Re: bin/43502: make failes to stip suffix if target is phony
Date: Wed, 30 Jun 2010 00:59:00 +0000
On Mon, Jun 28, 2010 at 09:45:02AM +0000, Wolfgang Stukenbrock wrote:
> 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.
It is 43534. I have attempted to add you but I'm not sure if it's
going to work.
I have just fixed that in HEAD. make on your example now prints
@ |t1.ttg|
* |t1|
@ |t2.ttg|
* |t2.ttg|
@ |t3.ttg|
* |t3|
It doesn't strip the .ttg off for t2 because it's not doing suffix
matching because it's PHONY. This seemed like the right behavior (and
it was also a much easier fix) but I'm open to argument.
The diff applies cleanly to both the -4 and -5 branches and I'll be
filing pullups in a couple days, assuming it doesn't cause anyone's
builds to turn to jelly or anything.
> 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.
Yes indeed.
One approach is to write for the common subset of gmake and BSD make,
which is less feeble than trying to allow for legacy SVR4 make too,
but that's still fairly cramped.
For things I do that really need to be portable I generally use awk
scripts to generate makefile fragments, mostly or entirely instead of
using make's own text processing. This approach has problems but it
appears to be the best alternative.
> 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.
Right. Although again, it doesn't work in gmake either...
> 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
> changed.
> 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.
Right.
There is no good mechanism for writing pattern rules in bmake. Even
ignoring the particular problem with .PHONY, suffix rules are not very
general.
In most cases writing a loop instead isn't a problem because you need
some kind of "all" target that also needs the list of all target
names. But it sounds like you aren't doing that here - instead you're
relying on someone typing "make foo.tg", right?
In that case there is a different approach :-) The magic variable
$(.TARGETS) contains the list of targets specified on the make command
line. So you can write something like
.for T in $(.TARGETS:M*.ttg)
$(T): $(T:S/.ttg$/.tg/)
do-some-stuff
.PHONY: $(T)
.endfor
and it should serve your purposes. Of course, this only works in
BSD make... but judging from the CVS history it should work in any of
the variants of BSD make, even the really old ones.
.TARGETS seems to be undocumented, though. This is a bug.
> 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.
I don't necessarily disagree with you; but since there doesn't seem to
be any convention for the precise interaction of suffix rules and
.PHONY it's not really safe to use it anyway, and because suffix rules
are unsatisfactory in general I'm not entirely inclined to rush to
make it work.
--
David A. Holland
dholland%netbsd.org@localhost