[En-Nut-Discussion] Assembly listings (.lst) placed in source directories

[Ulrich Prinz]

Hi!

I thought about that too. In some systems I found a solution, that 
places all compile-time files in one or multiple directories beyond the 
main directory. Like
my_app/gcc/object
my_app/gcc/lst
The binary, hex and map files are placed directly beyond my_app/gcc

This is interesting for systems that support multiple compilers. The gcc 
directory is generated by the makefile, by the way then.

It has a very neice sideeffect too, you can call SVN to ignore this 
directory and omit erroneous checkin of these compiler files. And you 
commit listing looks much smaller :)

It's a good idea, let's see what the others suggest to this.

Best regards, Ulrich

Am 15.02.2010 16:43, schrieb José Vallet:
> Hello all.
>
> .lst files are placed in the the source directories, at least in the
> example applications provided by NutOS (4.8.5). This becomes a problem
> if we want to separate source and compilation related files by, for
> example, creating a build directory.
>
> To illustrate the problem, let's take the hello_world application
> example and create a build directory
>
> What I do:
> 1-Create the bld directory in nutapp/hello_world
> 2-Move the Makefile to the bld directory
> 3-Modify the Makefile as:
> --------
> ...
> VPATH = ../
> ...
> include ../../Makedefs
> ...
> include ../../Makerules
> --------
>
> Then I call make from the bld directory.
>
> The problem is that the .lst files remain in the source directory, and
> thus making it to appear "dirty". Also, calling "make clean" does not
> remove the .lst file from the source directory, and therefore additional
> commands have to be written in the application's clean target to take
> care of deleting them.
>
> If I am not mistaken, the assembler options used by the apps are defined
> in the CPFLAGS make variable in nut/app/Makerules.arm-gcc (for arm and
> gcc), which reads
> ----------------
> CPFLAGS   = $(MCFLAGS) -Os -mthumb-interwork -fomit-frame-pointer -Wall
> -Wstrict-prototypes -fverbose-asm -Wa,-ahlms=$(<:.c=.lst) $(DEFS)
> ----------------
> Note that there is a previous definition in nut/Makedefs.arm-gcc, which
> is included by nut/app/Makerules.arm-gcc, but it is overridden by the
> definition in the later one.
>
> It seems that make substitutes "<" by "../uart.c", and therefore the
> substitution of "$(<:.c=.lst)" leads to "../uart.lst", which basically
> tells the assembler to store the .lst with the sources. If we change
> "-Wa,-ahlms=$(<:.c=.lst)" to "-Wa,-ahlms=$(@:.o=.lst)" as it appears in
> nut/Makedefs.arm-gcc, make substitutes it by "uart.o", and finally the
> .lst appears in the bld directory. Then also "make clean" works as it is
> supposed to.
>
> My questions:
> 1-Are the .lst files left in the source file directories on purpose for
> any specific reason that I ignore?
> 2-If not, would it be possible to keep them in a hypothetical build
> directory with the rest of the compilation-produced files?
> 3-If so, is the above proposed solution valid?
> 4-Why the CPFLAGS definition in nut/Makedefs.arm-gcc is overridden later
> in nut/app/Makerules.arm-gcc?
>
> And as always, if I am missing something any explanation is welcomed.
>
> Thanks and regards
> José
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion