[En-Nut-Discussion] Readability modification to Makefiles

Ulrich Prinz uprinz2 at netscape.net
Sun Mar 20 14:06:06 CET 2011


Hi all,

I'd like to suggest a rather big modification to the Makefiles in Nut/OS
and like to hear your opinions.

The make process output, if called from terminal or dos-box is a horror.
As the call sequence of any compiled file is dumped to the screen
important information can be missed quickly. To get a quick overview if
everything is going well you need to change you terminal window settings
to 140x80 at 8px fonts.

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.

I tested a couple of modifications to the Makefiles and found out that
it easy to break down the output to some readable thing.

So in my version a compiler run will look like this:

  [CC] foo.c
  [CC] bar.c
  [LN] foobar.o
  [HEX] foobar.hex
  [BIN] foobar.bin

What does the trick is the following:
%.elf: $(OBJS)
	@echo "  [CC] $@"
	$(CC) $(OBJS) $(LDFLAGS) -Wl,--start-group $(LIBS) $(ADDLIBS)
-Wl,--end-group -o $@

%.hex: %.elf
	@echo "  [HEX] $@"
	@$(BIN) $(BINFLAGS) -O ihex $< $@

%.rom: %.elf
	@echo "  [ROM] $@"
	@$(BIN) $(BINFLAGS) -O srec $< $@

By changing this declaration
TRGT   = avr-
CC     = $(TRGT)gcc
AR     = $(TRGT)ar
CP     = cp
to the following
TRGT   = avr-
CC     = @$(TRGT)gcc
AR     = @$(TRGT)ar
CP     = @cp
The makefile doesn't print its call sequence to the screen. But the
output from the called program is still printed. So just changing the
gcc to @gcc would result in nothing is printed. To have a small hint
where we are, the @echo "  [CC]} $@" is added to the make definition.

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.

This could be tightened up during this modification of the system too.

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.

So changing this will really improve the build system in visibility,
understandablity and speed.

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.

Please comment!

Regards, Ulrich


More information about the En-Nut-Discussion mailing list