How to deal with autoconf warning "'%'-style pattern rules are a GNU make extension"

Question

In a Makefile with

%.o: %.c
    @echo Compiling $< ...

I'm getting the warning '%'-style pattern rules are a GNU make extension when I run autoreconf --install (of autoconf version 2.69). The warning is not very clear, but makes me think that there's something to be added to configure.ac.

I conducted searches on google.com, duckduckgo.com and yahoo.com, but they all don't seem to be able to differentiate between the large number of build logs they index (why should they...) which makes the search painful. I figured that:

• I can silence the warning by adding AM_INIT_AUTOMAKE([-Wno-portability]) to configure.ac (found in a post of the openais mailing list) which seems not great because simply silencing a warning is generally not a good idea in a technical environment - please tell me if GNU autotools is an exception.

Zofiazoha

You don't give enough information. Do you use automake? Is that syntax with the pattern rule in your Makefile.am file? Or just autoconf, and the syntax is in your Makefile.in file? If the former, this rule is probably useless. If the latter, this rule should probably be written as a SUFFIX rule. What this warning is telling you is that your makefile contains GNU make-specific features (pattern rules are not part of the POSIX standard for make) and it won't work with other variants of make. You have to decide if you care or not. – Propellant

Also see Warning about GNU make extension with automake 1.10 on the Automake mailing list. – Lally

Answer 1

Replace

%.o: %.c

with

.c.o:

That's a suffix rule doing the same thing, and it's more portable. If your rule involves a suffix that is not known to make, list it in the prerequisites for the special .SUFFIXES target:

.SUFFIXES: .hack .win

.hack.win:
      # build a .win file from a .hack file.

More on how this works in detail here. They recommend to use pattern rules instead of suffix rules because they're clearer and more general, which is true, but as autoconf notes, they are indeed less portable. So if that is a worry (if you want to build on BSD/Mac OS and not install GNU make, basically), fall back on the "old-fashioned suffix rules."

If you have a pattern rule that cannot be replaced by a suffix rule, another possible replacement that automake doesn't complain about is a static pattern rule. This is similar to a pattern rule but requires a list of targets it applies to. Instead of saying

%.o: %.c

You would have to say

OBJS = foo.o bar.o baz.o # list all .o files here

$(OBJS): %.o: %.c

Or more generally,

target-pattern: prerequisite-pattern

is replaced by

target-list: target-pattern: prerequisite-pattern

Intermediacy

new version of autoconf 'asked' me to use SUFFIXES= .hack .win insetead of target .SUFFIXES – Agreeable

SUFFIXES += .hack .win – Agreeable

Is it possible to define suffix rule for building xyz from xyz.abc, the target has no suffix. – Dawson

Answer 2

Winteermute covered almost all aspects of the issue. I will add one of my own frustrations here. In my make file, I have been using a pattern rule to install shell scripts without their .sh suffix. Automake does not like pattern rules and give you warning. You can simply ignore the warning for now. My configure.ac file:

AM_INIT_AUTOMAKE([-Wall -Wportability])

In my Makefile.am

dist_bin_SCRIPTS = foobar

# pattern rule
% : %.sh
    cp $< $@
    chmod +x $@

In my script directory I have the foobar.sh file.

I have not been able to figure out a better way to specify a suffix rule to cover the case where the target does not have an extension although I really tried hard to search on the internet and read the manuals backward a few times.

The reason I am distributing the *.sh file is that the user does not have to know the implementation details. They just need to remember the name of the executable. Furthermore, asking the user to type the extra .sh is really a waste of life.

Dawson