build directory layout

[Massimiliano Cialdi]

hello to all
in my builds I need the build directory to be the exact mirror of the source directory, like in this example:

|-- build
|   `-- src
|       |-- main.c.lst
|       |-- main.c.o
|       |-- subdir1
|       |   |-- file1.c.lst
|       |   |-- file1.c.o
|       |   `-- subdir2
|       |       |-- file2.c.lst
|       |       `-- file2.c.o
|       `-- subdir3
|           |-- file3.c.lst
|           `-- file3.c.o
`-- src
    |-- main.c
    |-- subdir1
    |   |-- file1.c
    |   `-- subdir2
    |       `-- file2.c
    `-- subdir3
        `-- file3.c

(which is what CMake also does by default.)

I tried with the --layout option both `mirror` and `flat` but didn't get what I want.

How can I get such a directory layout from meson?

best regards

Max

[Jussi Pakkanen]

On Mon, 21 Dec 2020 at 17:13, Massimiliano Cialdi <cia...@gmail.com> wrote:

> (which is what CMake also does by default.)
> I tried with the --layout option both `mirror` and `flat` but didn't get what I want.
> How can I get such a directory layout from meson?

FWICT the output is the same apart from object files. Those always go
in the target private dir by design. Is this the case and if yes why
do you need to put the object in the main directory?

[Massimiliano Cialdi]

It is one of the requirements that have emerged as "convenient" over time, in the company where I work.

It is not only about the object files, but mostly about the listing files (.lst files).
The projects I'm involved in are aimed at microcontrollers. These are bare metal firmwares, with at most one RTOS scheduler. Everything is written by us. There are dozens of directories with many hundreds of .c files in them.

And .lst files are extremely useful in many aspects of debugging and profiling.
Searching for a specific .lst file among hundreds of others was much more difficult than searching for it in a specific well-known path. This convinced the company to impose this requirement.
In any case this is not written in stone, and maybe if the advantages of using meson are judged more "heavy" than this "disadvantage" we will have reached our goal.

best regards

Max

 

[Jussi Pakkanen]

On Mon, 21 Dec 2020 at 21:05, Massimiliano Cialdi <cia...@gmail.com> wrote:

> It is one of the requirements that have emerged as "convenient" over time, in the company where I work.
> It is not only about the object files, but mostly about the listing files (.lst files).
> The projects I'm involved in are aimed at microcontrollers. These are bare metal firmwares, with at most one RTOS scheduler. Everything is written by us. There are dozens of directories with many hundreds of .c files in them.
> And .lst files are extremely useful in many aspects of debugging and profiling.

What do those lst files contain and how are they generated? If you
create them yourself with a custom script or command, then the output
will go in the build directory where the the custom_target command is
defined. So if you have it in src_root/foo/meson.build the output will
go to build_root/foo/yourthing.lst.

If you need detailed information about each build target, you might be
able to get what you need using `meson introspect`. See:

https://mesonbuild.com/IDE-integration.html

The page says IDE integration because that is what the functionality
was originally written for, but the data is available to all tools
that need it.

[Massimiliano Cialdi]

If you use gcc you can pass parameters to the assembler. To generate file listings I use the parameter `-Wa,-anhlsd=<filename>.lst`

take a look at https://sourceware.org/binutils/docs-2.35/as/a.html#a

so in the gcc command line that you use to compile a .c file into an .o file, adding the above parameter instructs the toolchain to generate also the .lst file.
The requirement is that it is in the same relative position, so next to the .o

unfortunately the name of the .lst file that we want to produce must be indicated to the right of the equal (if you don't indicate it gcc emits it on stdout)

So I need to find a way to know the name of the .o file that is being generated to copy the basename and append the .lst.
Alternatively it would be enough to know the .c file that was being compiled and place the .lst in the same relative position with name .c.lst.

so there is no specific command or target to generate the .lst files, instead it is gcc that generates the .o and the .lst at the same time during compilation.

best regards

Max

[Jussi Pakkanen]

On Mon, 21 Dec 2020 at 23:05, Massimiliano Cialdi <cia...@gmail.com> wrote:

> If you use gcc you can pass parameters to the assembler. To generate file listings I use the parameter `-Wa,-anhlsd=<filename>.lst`
> take a look at https://sourceware.org/binutils/docs-2.35/as/a.html#a
> so in the gcc command line that you use to compile a .c file into an .o file, adding the above parameter instructs the toolchain to generate also the .lst file.
> The requirement is that it is in the same relative position, so next to the .o
> unfortunately the name of the .lst file that we want to produce must be indicated to the right of the equal (if you don't indicate it gcc emits it on stdout)

What is the specific problem that you are solving with these lst
files? The documentation is not really clear on what they are used
for.

[Massimiliano Cialdi]

On Tuesday, December 22, 2020 at 10:40:35 AM UTC+1 jpak...@gmail.com wrote:

What is the specific problem that you are solving with these lst
files? The documentation is not really clear on what they are used
for.

lst files contains generated assembler interleaved with c source. It contains very useful infos about global variables, their properties, allocations, sections, etc.

On embedded projects like ours these files are an invaluable help for profiling, but especially for debugging.

I encourage you to do a test (maybe actually with an arm-none-eabi toolchain like mine)

best regards

Max