[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] trace: weird issues with makefile dependencies
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] trace: weird issues with makefile dependencies |
Date: |
Tue, 22 Jan 2013 15:59:35 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Tue, Jan 22, 2013 at 03:27:26PM +0100, Paolo Bonzini wrote:
> Il 22/01/2013 11:00, Stefan Hajnoczi ha scritto:
> >> > I also just spent a long time trying to figure out why
> >> > my MacOS system wouldn't build after a git pull; turns
> >> > out that:
> >> > (1) we used to have a generated trace.h and we don't any more
> >> > (2) make distclean doesn't remove trace.h
> >> > (3) #include "trace.h" prefers the out of date generated one
> >> > to the new non-generated one in include/
> >> >
> >> > I have no idea whether we can make qemu's build process more
> >> > resistant to that kind of diachronic change, but I mention it
> >> > anyway :-)
> > Yes, this is an annoying weakness in the build system. But I think we
> > should not solve it with more make sophistication because we seem
> > incapable of handling the current level of complexity already :).
>
> To some extent there's nothing you can do. The only solution is to
> lower the build system churn---personally I'm satisfied with the current
> level of complexity, so I'll stop contributing to it. :)
>
> Forbidding in-tree builds is too much IMO, they're okay for occasional
> builders, but people using the git tree probably had better switch to
> out-of-tree if only because a "rm -rf _build" will fix any problem. We
> still have the buildbots to notify us about in-tree build problems, and
> of course people submitting build system patches should test both scenarios.
Why not seriously default to ./build/ for build products and get rid of
class in-tree builds?
The build still happens inside the working tree by default but it will
be in a dedicated ./build/ directory. We can easily rm -rf that
directory to eliminate all build products.
The only downside I see is existing developers, packagers, and testers
having to get used to ./build/x86_64-softmmu/qemu-system-x86_64 and
friends.
I think it's worth it if we can eliminate these time-consuming build
system glitches.
Stefan