[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 <Wolfgang.Stukenbrock%nagler-company.com@localhost>
Cc: gnats-admin%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost,
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
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
David Holland wrote:
> 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
> 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,
> Wolfgang.Stukenbrock%nagler-company.com@localhost 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
> 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
Main Index |
Thread Index |