help-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Why are circular rules not supported


From: Olivier Cailloux
Subject: RE: Why are circular rules not supported
Date: Tue, 22 Nov 2005 18:12:34 +0100

> DeĀ : Paul Smith
>   oc> It seems to me that they are harmless and usefull is some specific
>   oc> situation. For example, imagine a makefile with these three rules:
> 
>   oc> foo.pdf: foo.ps
>   oc>         (some rules to create a pdf from a ps file)
> 
>   oc> foo.ps: foo.pdf
>   oc>         (some rules to create a ps from a pdf file)
> 
>   oc> foo.ps: foo.dvi
>   oc>         (some rules to create a ps from a dvi file)
> 
> Note your second two rules can't both exist.  There can be only one
> explicit rule to build any given target.  If you write that makefile
> you'll get an error.

You are right, sorry. My original example was with pattern rules, but I
thought I'd simplify it as I thought that there was nothing pattern-specific
in my problem.

(Now I also wonder why it's not allowed to have only one explicit rule to
build any given target, but that's OT, let's stuck on the main question.)

> 
>   oc> Imagine that I execute "make foo.pdf" from a folder where a file
>   oc> "foo.dvi" exists. Then, there is only one reasonable way to create
>   oc> foo.pdf.
> 
> The only reason you know that is because you have a priori knowledge
> that make doesn't have.  Suppose you see a makefile like this:
> 
>     foo: bar ; <some rule to build foo from bar>
> 
>     bar: foo ; <some rule to build bar from foo>
> 
> When someone says "make", what do you do?

I don't think that I use more knowledge than what make can derive from 
the makefile. In your example, make has indeed to issue an error. Now let me
take an example like my first one, but with pattern rules instead.

%.pdf: %.ps
        (some rules...)

%.ps: %.pdf
        (some rules...)

%.ps: %.dvi
        (some rules...)

Here the second two rules are allowed AFAIU. It's the recursive part that
will cause make to output an error and avoid the recursivity by transforming
my rules. That is not the best behavior IMHO: make could see, when I issue
the command "make foo.pdf" in a folder where foo.dvi exists, that the only
possible way to satisfy my order is to use foo.dvi to create foo.ps (using
rule 3), then foo.pdf (using rule 1).

My point is that, even if giving potentially recursive rules in a make file
can lead to impossible situations, there are SOME situations where the
behavior to adopt is not ambiguous. E.g., my exemplary make file should be
allowed. Simply because there is no other way (except if I'm missing
something) to tell in a single makefile how to produce a pdf from a ps
(where a ps is available or can be derived from other means than going
through a pdf) AND how to produce a ps from a pdf (where a pdf is available
or can be derived from other means than going through a ps).

make simply has to refuse building "chained rules" containing something
recursive. But it should not automatically reject a makefile when it
contains potentially recursive rules.

I suppose this is too simple to be correct (else it would already be
implemented), but... What am I missing?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]