[En-Nut-Discussion] Readability modification to Makefiles

[Harald Kipp]

Hi Ulrich,

On 3/20/2011 2:06 PM, Ulrich Prinz wrote:

> While this is not to problematic for the Nut/OS build process as there
> the compiler is set very strict and any simple warning will cause an
> abort, compiling your application can inherit lots of warnings that you
> never see on the overloaded screen.

Agreed.

> What does the trick is the following:
...
> %.hex: %.elf
> 	@echo "  [HEX] $@"
> 	@$(BIN) $(BINFLAGS) -O ihex $<  $@

Putting this on every command line has a disadvantage. Sometimes I need 
to inspect the command for 2 reasons:

1. I want to copy the command to use it "offline" (without calling make).
2. Users often report problems, where the command output of make would 
show me, what's wrong.

If I want that output, there would be too many lines in too many files 
to be changed.


> TRGT   = avr-
> CC     = @$(TRGT)gcc
> AR     = @$(TRGT)ar
> CP     = @cp

That looks much better to me.


> There is a second enhancement from this. While changing all the
> makefiles I encountered lots of lines where programs are called directly
> and not by calling their declared placeholders. Especially the clean
> call is often referring rm directly instead of calling $(RM) the same is
> for strip, linker and others.

Yes, using macro expansion for every executable will further increase 
portability and simplify modifications.

Btw. once I tried to replace rm by del and cp by copy on Windows hosts. 
Can't remember why, but for some reason this failed.


> During the changing of the makefiles a second thing appeared. I ever
> wondered why the clean run does need such a big time to complete. By
> exchanging the rm -f to @rm -f I found out that lots of these are called
> multiple times. AFAIK I saw rm *.lst at least three times trying to
> delete the same files over and over again.

Remains from the days, where Nut/OS was tiny and compiling was slow. 
Today CPUs are compiling fast while file system accesses did not improve 
much.


> But here is the problem: I can implement and test this for AT91SAM7 and
> CortexM3 but I cannot tell if the build for AVR and other chips
> generates usable code even it doesn't show any failure. So someone needs
> to check that for me.

No problem, I've everything installed on my machine to run

nut/tools/packaging/distcheck.lua


Thanks,

Harald