[En-Nut-Discussion] Make hides compiler command lines
ulrich.prinz at googlemail.com
Thu Jul 5 22:08:23 CEST 2012
Am 04.07.2012 09:56, schrieb Harald Kipp:
> Hi Ulrich,
> On 03.07.2012 22:36, Ulrich Prinz wrote:
>> the intention of that hiding was simple: Overview.
>> The silencing was only a side effect of finding all the points
>> where a new compiler has to be added in the Makefiles. I remember
>> that I collected all the tools in one file and defined them there.
>> I replaced all bla-blub-gcc by $(GCC) and all rm by $(RM),
>> bla-blub-ld by $(LD) and so on.
>> So silencing was only a simple thing GCC=$(CROSS_COMPILE)gcc is
>> printing every call and a @ in front GCC=@$(CROSS_COMPILE)gcc
>> avoids that printing something.
> But unfortunately it is not done that way. Instead we have
Sorry my fault!
I'd better wrote CC=$(CROSS_COMPILE)gcc but to be honest it is even
I think I used TRGT as the CROSS_COMPILE, so
> Makerules.gcc: @$(CC) -MM $(CPPFLAGS) $(CFLAGS) -o $@ $<
> Makerules.gcc: @$(CC) -c $(CPPFLAGS) $(CFLAGS) -o $@ $<
> Makerules.gcc: @$(CXX) -c $(CPPFLAGS) $(CXXFLAGS) -o $@ $<
> Makerules.gcc: @$(AS) -c $(CPPFLAGS) $(ASFLAGS) -o $@ $<
> Makerules.gcc: @$(AR) $(ARFLAGS) $@ $?
> Makerules.all: @-rm -f $(SRCS:.c=.bak)
> Makerules.all: @-rm -f
> Makevars.all:CP = @cp
> Makevars.gcc:AR = @$(TRGT)ar
> Makevars.gcc:CP = @cp
> Makevars.gcc:RM = @rm -f
yes, I ran into protest from you and others and stopped merging my local
version of makefiles. So the final version never made it into devnut_m3n.
That is the reason why only some of your builds do not show so much infos.
At our site we defined for coding rules, that makefiles print their
setups once and then beeing as silent as possible and the output should
be formatted in a way to present any abnormal information.
So we do echo "LDFLAGS: $(LDFLAGS)" and such in the beginning (or when
something changes later) and then we just like to see
> Still no big deal to change them, but I have to do this after each
We could fight about the verbosity of the make process, but I guess we
should unify all direct program calls to be variable calls ( rm should
be $(RM) and we should unify where the variables are preset.
I know your LUA thing but I am not familiar with it and try to stick
with Makefile and bash. It is more easy and does not require
installation of additional packages and training of colleagues.
make: Leaving directory
> make -C caltime make: Entering directory
> " [CC] caltime.c" caltime.c: In function 'main': caltime.c:379:24:
> error: 'devUart0' undeclared (first use in this function)
> caltime.c:379:24: note: each undeclared identifier is reported only
> once for each function it appears in make: *** [caltime.o] Error
> 1 make: Leaving directory
> make: *** [all] Error 2
> This gives a nice overview about all unsolved problems. Of course you
> could do something similar with DOS batch files or shell scripts.
I do not have DOS anymore. Neither at hom nor at work is any DOS or
Windows involved in my development things. I only have some XP and Win7
VMs for compliance testing and for this fat ship called Lotus Notes that
never cleanly installs on Linux.
> As a side effect of the "@" silencing, this script also does no
> longer list the command line, which sometimes contained valuable
> informations, specifically when adding new devices.
As I told, we output the command line once in front. Or we enable verbosity.
>> Btw. I added "make burn" as a second 'programming' target. It
>> simply programs without recompiling anything, what is helpful if
>> you just need to test your things on a series of targets.
> Do you remember, where you needed to add this? Just curious, because
> I'm using "make burn" (without recompiling) for years.
Ok, one I added program: as a new target as burn had all as the first
rule in the Makefile.
Are you sure it is the same thing in all targets? I am pretty sure I
copied the involved Makfile for cm3-oocd from the arm version. May be
there are differences too.
More information about the En-Nut-Discussion