Follow-up Comment #15, bug #48643 (project make): > Are you saying that this also should be the correct behaviour?
I now realize, that inadequate description of example 3 was provided and caused misunderstanding. Let me provide a more verbose description. Make has to do both skip unrelated rules and stay compatible with the makefiles that depend on unrelated rules. Example 3 is depends on unrelated rules. Make-4.3 successfully builds example 3 and the fix has to take care to keep building it. Let us repeat example 3 here. Example 3. ++++ all: hello.tsk %.tsk: %; $(info $@ from $<) unrelated: hello ---- In example 3 rule '%.tsk: %' is chosen to build 'hello.tsk', because 'hello' is mentioned explicitly on an unrelated rule. Builtin rule '%: %.f' is chosen to build 'hello' from 'hello.f', because 'hello.f' exists. The chain is hello.tsk <- hello <- hello.f. Patch-v2 fails example 3. Patch-v1 has code to handle this use case and is capable of building example 3. However, i believe, there are other issues with patch-v1, described below. Let us say hello.f is present in the filesystem and consider the following example. Example 4. ++++ all: hello.tsk %.tsk: %; $(info hello.tsk) %: %.f; $(info hello.f) ---- Make looks for a rule to build 'hello.tsk' and considers '%.tsk: %'. '%' expands to 'hello'. There is no file 'hello' and 'hello' does not qualify as % ought-to-exist. There is rule '%: %.f' which can be used to build 'hello' from 'hello.f', because 'hello.f' exists. However, make rejects rule '%: %.f', because 'hello' is an intermediate. The manual does not allow match-anything rules to build intermediates for performance reasons. The original make authors made this (good imo) design choice and put this restriction in the manual. See "10.5.5 Match-Anything Pattern Rules.". Both make-4.3 and dgfix fail example 4. Patch-v1, however, allows match-anything rules to build intermediates. Patch-v1 causes makes to build 'hello' from '%: %.f' and then 'hello.tsk' from 'hello.' This is the major issue with patch-v1. This is not a bug fix any longer. This is a new and an expensive undesired feature, accidentally sneaked into make. If patch-v1 is applied and released, then users will start writing makefiles which depend on this feature. This will slow down make, including for those users who do not even use this feature. Once this feature is released, it will be very difficult to undo. Another issue with patch-v1 is that we don't know which uses cases it fails to be compatible with. Let us say hello.c and hello.tsk are missing and consider the following example. Example 5. ++++ all: hello.tsk %.tsk: %.c; gcc -o $@ $< .DEFAULT:; echo 'int main() {}' > $@ unrelated: hello.c ---- Here, make chooses rule '%.tsk: %.c' to build hello.tsk, because hello.c is mentioned on an unrelated rule. Make then finds the default rule to build hello.c. Both make-4.3 and dgfix support example 5. Patch-v1 fails example 5. I attempted to modify the search algorithm to support all the possible use cases and concluded that the most reliable and the simplest is the algorithm that performs compatibility search, presented above. We can reason that the compatibility search supports all uses cases that make-4.3 supports, because compatibility search is the same as the current search of make-4.3. > here's only a difference between the implementations when the Makefile isn't going to work anyway i hope, this demonstrates that there are other differences. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?48643> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/