In message 20060828165250.6ad2c6c3@cad-250-152.norway.atmel.com you wrote:
I'm sorry, but you're addressing the rong end of the problem here. Please submit a bug report to the make folks, and try to fix make.
If it's truly a bug in make, sure.
Any "make" gurus around to comment?
%: %.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.
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.
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).
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 ;-)
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.
Best regards,
Wolfgang Denk