[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: make: avoid breaking backwards compatability
On Fri, 05 Sep 2014, Jarmo Jaakkola wrote:
If there is an explicit dependency without commands, then the
search implied by .SUFFIXES is NOT performed, but the file
names are checked to see whether they end with known suffixes.
(If a target explicitly depends on multiple sources, then
only the first source gets this treatment.) The suffixes
from the first explicit dependency select an appropriate
.suffix1.suffix2 rule, if it exists, and the commands in that
rule are performed.
I partly agree. I'd say: take the name of the target
(dir/target.x), then take all suffixes .y from which .x can be
made (in .SUFFIXES order) and see if the first dependency is
"[prefix/]dir/target.y". If it is, use that one. Otherwise do
a normal suffix rule search.
I had thought that my wording was closer to the existing (old)
behaviour, but my tests indicate that your wording better
expresses the existing (old) behaviour, so lets go with your
Then the question is if "prefix" should be in .PATH for the
dependency to be approved. I.e. is this "choose one eligible
candidate explicitly" or "use this file regardless of if it
could normally be used".
The exising (old) behaviour is that the source file's direcroey
does not need to be listed in .PATH. We should retain this.
Also, do we want multi-stage transformations:
foo.z: foo.x # foo.x -> foo.y -> foo.z
I'd say no, because now you're saying that foo.z depends on
foo.x, while in reality foo.z depends on foo.y, which depends
on foo.x. Not to mention that it would probably necessitate
implementing the suffix search in reverse. And you could still
Multi-stage transformations are OK for the case where there are no
explicit rules, but where there are explicit rules, I think users
should list all steps explicitly.
(If the files in the explicit dependency do not have known
suffixes, or there is no .suffix1.suffix2 rule, then nothing
I strongly disagree. This will break approximately all
makefiles ever written. Consider:
foo.o: foo.h other.h
Surely what this means is that foo.o is to be made from foo.c,
but the object file also depends on the headers foo.h and
other.h and must be recompiled when they change.
For the meaning you describe, I would expect the makefile to say:
foo.o: foo.c foo.h other.h
However, my tests indicate that the old make would have behaved as you
describe, so it's fine to retain that behaviour.
--apb (Alan Barrett)
Main Index |
Thread Index |