[bug #63840] make allows match-anything rules to match files with the default suffixes

[Dmitry Goncharov]

Follow-up Comment #5, bug#63840 (group make):


> Sorry for the delay in examining this bug.

Thank you for looking at this.

...
> However, I tend to agree with you that this is perhaps too much "inside
baseball" for the default behavior. 

i also think, this is too much to be useful. E.g. in your example should not
.SUFFIXES: also list .h?

> I think you are mostly correct in your determination of the problem with one
exception: when the .SUFFIXES list is cleared explicitly, then we should not
create any dummy pattern rules and thus these match-anything rules SHOULD be
matched.

Well, this bug report (and the attached patch) was only intended to ensure
that when -r is specified, match-anything rule are not eligible for .c, .h,
etc files.

For the reasons presented in comment 3, i like the current behavior, that when
.SUFFIXES is cleared, then match-anything rules are still not eligible for .c,
.h, etc files. i feel, this behavior is more suitable for match-anything
rules. In the end, match-anything rules were created to build binaries which
have no suffixes (like 'cp'), not .c files. Maybe we can update the manual to
say that match-anything rules do not build files with built-in list of known
suffixes, whether .SUFFIXES is cleared or not?



> What we should probably do is not clear the .SUFFIXES list by default when
-r is given, but instead simply not create the default rules associated with
those suffixes.

Would not that contradict the manual?
E.g. if the makefile contains


.c.o:
        $(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $<


and -r is specified, then make should take '.c.o' as a target name, rather
than as a suffix rule.
If .SUFFIXES is not cleared, then will make take '.c.o' as a target name or as
a suffix rule?

> I have a simple patch that does that; if you agree that's OK I'll push it
along with your tests.

i'd need to see the patch to comment. Do you think you can post the patch?


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63840>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/