qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: more findable locations for compiled/generated files in the build tr


From: Paolo Bonzini
Subject: Re: more findable locations for compiled/generated files in the build tree?
Date: Fri, 9 Oct 2020 10:40:51 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0

On 08/10/20 23:33, Peter Maydell wrote:
> Is it possible to get Meson to put the files that are
> generated/compiled as part of the build process in more
> sensibly findable locations?

Short answer: no.  You won't be surprised I guess.

> I would generally expect
> that a file foo.c should generate into foo.o, and
> foo/bar.c should generate into foo/bar.o, and if we
> generate a .c file from foo/bar.decode then it ought
> to end up in foo/bar.c or something similar.
> The old build system got all this generally right.

Except for recursive make.  So for example foo/bar.decode did not go in 
foo/bar.c, it went to ARCH-softmmu/foo/bar.c (more precisely into 
target/arm/decode-bar.inc.c).  Not that Meson removed this special
case, but the directory structure generated by Meson is still a fairly
regular one, and there's generally a mapping from old to new:

  *.o from FOO-obj-y    -> libFOO.fa.p/DIR_*.c.o
  ARCH-softmmu/*.o      -> libqemu-system-ARCH.fa.p/DIR_*.c.o
  ARCH-softmmu/*.inc.c  -> libqemu-system-ARCH.fa.p/*.c.inc (no directory here)
  other generated files -> unchanged

with the caveat is that / becomes _ in the directory (I suppose it's
to avoid making the hundreds of empty subdirectories that we had too).

The rationale for putting each target's object files in a separate directory
actually matters a lot QEMU: it makes it trivial to build a file multiple
times with different flags and/or include paths.  If you think about it, it
is on the contrary quite hard to achieve that with Make, and it was the whole
reason why QEMU had recursive Makefile.target and the binaries ended up in
subdirectories like x86_64-softmmu/qemu-system-x86_64.

Anyway, here are some examples:

  old                                      new
  --------------------------------------   
--------------------------------------------
  common-obj-y += dma-helpers.c            libcommon.fa.p/dma-helpers.c.o
  arm-softmmu/target/arm/translate.o       
libqemu-arm-softmmu.fa.p/target_arm_translate.c.o
  arm-linux-user/linux-user/arm/cpu_loop.o 
libqemu-arm-linux-user.fa.p/linus-user_arm_cpu_loop.c.o
  arm-linux-user/target/arm/decode-t32.c   
libqemu-arm-linux-user.fa.p/decode-t32.c.inc
  qapi/qapi-events-net.c                   unchanged

Out of curiosity, what do you use the placement of the output files for?
I generally just use touch on the source (rather than rm on the target)
if I want to force-rebuild something.  For the case where I need to
objdump a .o file or look at the generator output, I cut-and-paste
from the Make output; for example:

  Compiling C object libcommon.fa.p/dma-helpers.c.o
  Compiling C object libqemu-arm-softmmu.fa.p/target_arm_translate.c.o
  Generating 'libqemu-aarch64-softmmu.fa.p/decode-t32.c.inc'.

Paolo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]