On Mon, 28 Aug 2006 16:35:23 +0200 Wolfgang Denk wd@denx.de wrote:
Dear Haavard,
in message 20060828162247.6a33963d@cad-250-152.norway.atmel.com you wrote:
This patch fixes the following problem:
make[1]: *** No rule to make target `hello_world.srec', needed by `all'.
The problem has been reported several times before, but so far no patches have been accepted and no one has fixed make. In fact, I can't even find any relevant bug reports against make.
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.
This patch takes a slightly different approach than the other patches I've seen on the mailing list, as it lists the targets explicitly before each of the pattern rules for the elf-, srec- and bin-files. The dependencies for each target are correctly specified, so we don't
Does this mean that you think the current Makefile definition contains any "incorrectly specified" build rules? IF so, I would appreciate if you could point out where you see problems.
I'm pretty sure the problem is the "catch-all" rule for generating ELF files:
%: %.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.
As an added bonus, this gets rid of some duplication as each architecture, cpu, board, etc. only needs to add stuff to the ELF variable. The SREC and BIN variables are calculated automatically from the ELF variable.
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.
If you mean different CFLAGS and such, you can still use target- or pattern-specific variables.
I'm not going to check in this patch, as it only hides a serious problem. If "make" is broken on a level where it's operation depends on the order of target names, then this should be noted, so the use of this broken version can be avoided, and eventually "make" be fixed. Even if we fix this place, we've seen a couple of other cases where similar problems happen with this broken version of make. It IMHO makes no sense to add work arounds for a broken tool.
This patch does not change the order of target names. If anything, it makes the makefile more robust by specifying exactly what targets you want to apply the pattern rules to.
Let's have the tool fixed instead.
Sure, if the tool indeed is broken. Now, it's your turn to say what you think `make' is doing wrong ;)
Haavard