qemu-trivial
[Top][All Lists]
Advanced

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

Re: [Qemu-trivial] [PATCH 4/4] fix compilation when reconfiguring withou


From: Stefan Hajnoczi
Subject: Re: [Qemu-trivial] [PATCH 4/4] fix compilation when reconfiguring without dtrace backend
Date: Mon, 9 May 2011 09:34:29 +0100

On Mon, May 9, 2011 at 7:53 AM, Paolo Bonzini <address@hidden> wrote:
> On 05/08/2011 01:15 PM, Stefan Hajnoczi wrote:
>>
>> I think the real problem is that dependencies need to be regenerated
>> after ./configure?
>
> There are three ways to do that, the trivial but wrong one, and the correct
> but overzealous one:
>
> - delete .d files.  This forces regeneration of dependencies, but if you do
> not correspondingly delete .o files, you will likely have an incomplete
> build (possibly _nothing_ will be built).
>
> - delete .d and .o files.  This forces regeneration of dependencies and
> recompilation.  True, a lot of distros are using ccache nowadays, but still
> this will cause a complete walk of all directories to pass those files to
> ccache and relink the executables.  It will likely take a minute or three.

The .o files should depend on GENERATED_HEADERS (especially
config-host.h) and therefore be rebuilt by make when ./configure
outputs a new configuration.  If the configuration is identical an
unnecessary rebuild is triggered but this can be mitigated using
ccache like you say.

So I think just deleting .d files is enough.  BTW the Makefiles don't
seem to have a step before compilation to generate all the
dependencies, instead dependencies only kick in after the first build
has completed?

> - detect changes in the configuration and, if those happen, delete .d and .o
> files.  This is the correct one, and for one what the Linux kernel makefiles
> do, but also the biggest effort to implement.

Is there some smart change detection you are thinking about or just
something like keeping the old copy of config-host.h and friends to
see if they have changed?

Stefan



reply via email to

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