On 8/28/06, Wolfgang Denk wd@denx.de wrote:
In message 20060828165250.6ad2c6c3@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