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

[José Vallet]

Hello all.

Just trying to give a quick solution for those who might have the same 
problem.

What I have done is simply override the definition of CPFLAGS that 
appears in app/Makedefs.arm-gcc by defining it again in the Makefile of 
my application. In this redefinition I simply change 
"-Wa,-ahlms=$(<:.c=.lst)" to "-Wa,-ahlms=$(@:.o=.lst)".

Be sure to place the definition after the inclusion of the Makedef 
generated automatically by nutconf when creating the sample directory 
(nutapp/Makedefs). In the case of the hello_world example the Makefile 
would look like this:
--------------------
.....
include ../Makedefs
.....
#Override the definition of CPFLAGS
CPFLAGS   = $(MCFLAGS) -Os -mthumb-interwork -fomit-frame-pointer -Wall 
-Wstrict-prototypes -fverbose-asm -Wa,-ahlms=$(@:.o=.lst) $(DEFS)
.....
--------------------


Ulrich Prinz wrote:
> 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.

Interesting, didn't think of this option.

> 
> 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 :)

This is, together with keeping source dirs clean, one of the reasons why 
I want separate directories for sources and builds.


Now let me guess the answers to my own questions.

>> My questions:
>> 1-Are the .lst files left in the source file directories on purpose for
>> any specific reason that I ignore?

I cannot find any

>> 2-If not, would it be possible to keep them in a hypothetical build
>> directory with the rest of the compilation-produced files?

I guess so. At least I cannot find any reason why not.

>> 3-If so, is the above proposed solution valid?

I guess so. At least it works for me :). Note also that it does not 
force the users to separate source and build dirs, it works in both cases.

>> 4-Why the CPFLAGS definition in nut/Makedefs.arm-gcc is overridden later
>> in nut/app/Makerules.arm-gcc?

Maybe because simply the developers wanted to pass different flags to 
the compiler depending on what is being compiled (NutOS libs vs. apps).
The differences in both definitions are:

In the Makedefs.arm-gcc in the nut directory (for compiling NutOS) we 
find the following flags used to compile NutOS that we don't in the other:
-Werror -> Make all warnings into errors
-Wa,-ahlms=$(@:.o=.lst) -> discussed in this thread
$(UCPFLAGS) -> I have not found the definition of this one

In the Makedefs.arm-gcc in the app directory
-fverbose-asm -> Put extra commentary information in the generated 
assembly code to make it more readable
-Wa,-ahlms=$(<:.c=.lst) -> discussed in this thread

So the main differences are that all warning are turned into errors when 
compiling NutOS and extra comments are added in the assembly code when 
compiling apps.

Regards
José