Re: make: avoid breaking backwards compatability

[Alan Barrett <apb%cequrux.com@localhost>]

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 
version.

> 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 
> write:
>
>    foo.z: foo.y
>    foo.y: foo.x

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 
> > happens.)
>
> 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)