Re: unexpected behaviour with match anything rule

[Britton Kerin]

On Fri, Nov 16, 2012 at 7:14 AM, Philip Guenther <address@hidden> wrote:
> On Fri, Nov 16, 2012 at 11:34 AM, Christof Warlich
> <address@hidden> wrote:
>> Am 15.11.2012 21:08, schrieb Britton Kerin:
>>> Match-everything rules are really prone to problems of this sort.  The -d
>>> flag will give you a big pile of output that will tell you whats going on
>>> if you can stand wading though it.
>
> Any if you don't understand why your Makefile is doing what it's
> doing, you need to learn to read through it.  There are more buggy
> makefiles than there are bugs in make.
>
>
>>> Really its better to just not use implicit rules.  Compute the set of
>>> targets
>>> you want your rules to apply to with $(patsubst %.c,%.o,$(wildcard *.c))
>>> or so and use a static pattern rule.  It makes it easier to get the
>>> correct set
>>> of files, and make is more likely to give you a useful error message when
>>> things go wrong.
>
> Personally, I disagree.  You lose chaining when you do that, if nothing else.

Actually that's another good reason not to use them.  You have to name your
intermediate files as well to get the results of chaining, but this is a good
thing.  Its chaining that causes implicit rules to generate the really
misleading error messages.  The original poster was bitten by unintentional
chaining.

Implicit rules promote weird action-at-a-distance: you can't tell from
looking at
a given implicit rule whether it will apply without inspecting the
entire Makefile.
With static pattern rules you just have to trace back the variables that specify
the file set.  The tiny bit of additional writability isn't worth the
huge readability
hit.

> I'll also note that using $(wildard *.c) to find source files means
> that it won't
> work with VPATH and is fragile, breaking if someone does something like
>     cp main.c orig_main.c
>     <edit main.c>
>     make

Well, you can be as careful as you want in specifying your file sets, you
don't have to use wildcard.  In the above case the linker will give an
easily understood error message.

Britton