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: Peter Maydell
Subject: Re: more findable locations for compiled/generated files in the build tree?
Date: Fri, 9 Oct 2020 11:07:07 +0100

On Fri, 9 Oct 2020 at 09:40, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> 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.

Not really. As usual I find Meson really annoying to deal
with: it doesn't do things in the generally-standard-for-C-and-Unix
way by default, and it isn't flexible enough to be
configurable to do so. One of these days we're going to
find that its persistent inflexibility prevents us doing
something important rather than merely being an irritant.

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

That's not recursive make particularly, it's just that if
we want to build the same file twice we need to have a
subdirectory for each way of building it, as you note.
But in each of those subdirectories you can still use the same
directory layout the source tree has, which is what we
did with the old build system.

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

This is a silly scheme, because now you have an unnecessary
restriction that you can't have both foo_bar.c and
foo/bar.c. We don't have to pay for builds by the
subdirectory :-)

> 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'.

Generally at the point where I think "oh, maybe I should look
at the generator output" the output from make is no longer on
my terminal. So I just find the object file in the build tree
(not just for QEMU, but for anything I'm working on: IME
most projects put the object files in easy to guess places).

thanks
-- PMM



reply via email to

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