tech-toolchain archive

[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 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)

Home | Main Index | Thread Index | Old Index