bug-make
[Top][All Lists]
Advanced

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

Re: '... | Avoiding implicit rule recursion for rule '%/dir: %'. | ...'


From: WaitronCharm
Subject: Re: '... | Avoiding implicit rule recursion for rule '%/dir: %'. | ...'
Date: Thu, 07 Nov 2024 08:48:35 +0000

On Wednesday, November 6th, 2024 at 9:51 PM, Dmitry Goncharov 
<dgoncharov@users.sf.net> wrote:

> Maybe the authors had some other reason, but the only reason i can see
> today for implicit rules (other than match-anything rules) is
> avoidance of infinite recursion in cases like the following
> 
> all: hello.tsk
> %.tsk: %.o; $(info hello.tsk)
> %.o: %.c %.tsk; $(info hello.c)

Wouldn't this result anyway in a cyclic graph due to '%.tsk'? Could imagine one 
'tsk' dependent on some other 'tsk' but not (indirectly) self:

all: hello.tsk
%.tsk: %.o; $(info hello.tsk)
%.o: %.c dir/prefix_%.tsk; $(info hello.c)

What I meant in my earlier email is that protecting from infinite recursion 
should not happen by forbidding recursion completely.

> How do you teach make to allow some, but not infinite recursion?

Ends of the potentially infinite dependency graphs could be 'anchored' with 
additional explicit non-pattern rules. It is up to the 'makefile' author to 
guarantee this:

%/dir: %; # mkdir $@
---> target/dir/dir/file: target/dir/dir; # touch $@
---> target:; # mkdir $@

> A command line switch may not be the best option here. No user will
> know to specify the switch. A better option is a special target. A
> special target is mentioned in the makefile and relieves the user from
> knowing or specifying a switch.

Yes, good point.

> i don't see complications, as long as the behavior of match-anything
> rules stays intact.

Would this be then (1) check out the code, (2) add a new special target, (3) 
instead of 'break' simply continue around line 'Avoiding implicit rule 
recursion for rule', (4) compile and see the result?

What I meant by complications is whether the implementation uses the pattern 
rule name as some 'identifier' in any structures and multiples of the same 
pattern rule name (per target) would cause mess. (New 'identifier' could change 
to the combination of pattern rule name and instance no. of applying that rule).

I am not familiar with the 'make' code and did not look into it yet. Want to 
just estimate how much work would this be.



reply via email to

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