[U-Boot-Users] [PATCH] Fix/workaround broken dependency handling with make 3.81

[Håvard Skinnemoen]

On 8/28/06, Wolfgang Denk <wd at denx.de> wrote:
> In message <20060828165250.6ad2c6c3 at cad-250-152.norway.atmel.com> you wrote:
> > %: %.o $(LIB)
> >
> > This target matches absolutely anything, and it's not clear from the
> > make documentation that this is a valid rule. In fact, a target which
> > consists only of "%" has a special meaning, as explained in "10.6
> > Defining Last-Resort Default Rules" in the make manual. It does say
> > that a "catch-all" rule should have no prerequisites, however, so I
> > could be wrong about this.
>
> Section "Overriding Part of Another Makefile" has an example with  %:
> which looks not too much different to what we do.

That section is about catch-all rules, which I believe is actually
quite different from what we intend to do.

> I can accept to get error messages in case of Makefile errors, but  I
> think  no  matter  what is wrong ion the Makefile it should never (a)
> just silently do something wrong without even a warning, and (b)  the
> behaviour of Make must never depend on the order in which targets are
> given  -  this  alone  is for me a pretty strong hint that there is a
> make bug.

It doesn't fail silently -- it complains that it can't find any rules
to make hello_world.srec. Although I agree it's a bit worrying that
everything is suddenly fine when hello_world is a prerequisite of
"all"...

> > > On the other hand you lose the ability to have different settings for
> > > SREC and BIN targets.
> >
> > What kind of settings? I didn't see anything special in the existing
> > makefile.
>
> I might want to build foo, foo.srec and foo.bin,  but  only  bar  and
> bar.srec (no bar.bin), or baz and baz.bin (no baz.srec).

Why? To shave half a second off the build time? ;-)

Anyway, I can make a new patch that assign the ELF, SREC and BIN
explicitly. Would that be acceptable?

> > Sure, if the tool indeed is broken. Now, it's your turn to say what you
> > think `make' is doing wrong ;)
>
> It refuses to do what I tell it. That's a major offense ;-)

Now, what _do_ you tell it, though? Basically, you're saying `make' is
free to build _anything_ from a .o file and $(LIB). This can actually
be quite dangerous -- consider the following Makefile (NOTE: don't run
it with files you care about in the same directory, including the
Makefile itself):

all: hello_world.tgt

%.tgt: %
        cp $< $@

%: %.src
        cp $< $@

%.src: FORCE
        touch $@

.PHONY: FORCE
FORCE:

When executing make, this is what happens (same result with make 3.80 and 3.81):

touch Makefile.src
cp Makefile.src Makefile
rm Makefile.src
make: *** No targets.  Stop.

What prevents make from doing this with your Makefile?

> Seriously: the make result must never depend on the  order  in  which
> targets are given; and if there is a bug in the Makefile, I expect to
> see a (helpful) error message instand of random behaviour.

Yeah, but the jungle of internal implicit rules, remaking of Makefiles
and such is not easy to understand. I for one don't.

I'll send a mail to the make mailinglist tomorrow to see if anyone can
give an explanation.

Haavard