Follow-up Comment #1, bug #62706 (project make):

Second expand only the prerequisites of the targets being built.
Avoid second expanding the prerequisites of targets which are not being

There are multiple benefits.

1. Avoids redundant work of second expanding prerequisites of the targets
which are not being built.

Example 1
hello.tsk: $$(info 2nd exp for hello) $$(file <hello.d); $(info $@ from $^)
bye.tsk: $$(info 2nd exp for bye) $$(file <bye.d); $(info $@ from $^)
clean:; -rm -f hello.tsk bye.tsk

Assuming there are files 'hello.d' and 'bye.d' which contain the prerequisites
of 'hello.tsk' and 'bye.tsk' respectively

$ make hello.tsk
second expands $$(file <hello.d), but does not second expand $$(file bye.d).

$ make clean
does not second expand either $$(file <hello.d) or $$(file <bye.d). 

2. Causes all prerequisites to be second expanded in the same order they are
being built. This fixes byte order dependent order of second expanding
prerequisites. See sv 62175.

3. Eliminates redundant files from the make's database, which reduces the size
of the hash table and memory consumption.

4. Prevents side effects from second expansion of unrelated prerequisites. 
Even though we'd prefer makefiles which do not depend on side effects, the
current behavior allows them.

Example 2
hello.tsk:; cp hello.1 $@
unrelated: $$(shell touch hello.1);

The current behavior is to second expand $$(shell touch hello.1) during parse
phase and thus create 'hello.1'. This allows 'cp hello.1 $@' to succeed.  The
new behavior is such that when 'hello.tsk' is built, $$(shell touch hello.1)
is not second expanded, and thus $$(shell touch hello.1) fails.

Another size effect is that, because the prerequisites of unrelated targets
are not second expanded, those prerequisites may end up being treated as
intermediates, where before this commit they would be treated as explicitly

Example 3
all: hello.z
%.z: %.x; @echo $@
%.x: ;
unrelated: $$(dep)

In example 3 the old behavior is to second expand $$(dep) at parse time and
thus enter file 'hello.x' to make's database prevent 'hello.x' from being
intermediate. The new behavior is $$(dep) is not expanded and 'hello.x' is not
entered and thus 'hello.x' is intermediate.

Both of this examples are artificially created to demonstrate side effects and
are not very realistic.  Normally, an automatic variable would be second
expanded, otherwise, there is really no point to second expand prerequisites
at all.

i checked automake and cmake and found no dependency on such side effects. As
far as i can see, most projects do not use second expansion.

However, if make has to retain side effects, it is possible to introduce
another special target with the new behavior.

5. Implicit rules have behaved in this manner since day 1. This patch causes
explicit and static pattern rules behave like implicit rules and do the
required work only.


Reply to this item at:


Message sent via Savannah

Reply via email to