qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

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