> De : Paul Smith > oc> make simply has to refuse building "chained rules" containing > oc> something recursive. But it should not automatically reject a > oc> makefile when it contains potentially recursive rules. > > You are suggesting changing the above algorithm so that detection of a > recursion would cause that pattern to not match, but would allow > subsequent patterns to continue, is that correct?
Indeed. An other suggestion could be to allow several explicit rules to build a given target, using different prerequisites, but I don't know if it would be useful to many people. It's more from a coherence point of view (as it is allowed for pattern rules). What do you and the readers here think about it? If they seem to be a good idea, is there some "suggestion list" where I could submit these suggestions? > oc> Simply because there is no other way (except if I'm missing > oc> something) to tell in a single makefile how to produce a pdf from > oc> a ps (where a ps is available or can be derived from other means > oc> than going through a pdf) AND how to produce a ps from a pdf > oc> (where a pdf is available or can be derived from other means than > oc> going through a ps). > > Well, you could do something like this: > > ifneq (,$(filter %.pdf,$(MAKECMDGOALS))) > %.pdf : %.ps > ... > else > %.ps : %.pdf > ... > endif > > And you could make it even fancier by using $(wildcard ...) to test > whether files of certain types existed. Not very nice, but it's > something. Nice workaround, but workaround only ;-). Now suppose (in a more complex makefile including those rules and other ones) that my main goal is something else than a PDF, but a PDF is required as an intermediate file. Not allowing recursions at all in a makefile has the effect of disabling some of the power of make, who is normally able to find itself the correct rules to use to build the goal. Olivier _______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
