On 09/28/2012 06:25 AM, Eric Blake wrote:
> On 09/27/2012 09:51 PM, liguang wrote:
>> if gnulib submodule happened to be dirty, build
>> process will fall into '_autogen' target trap
>> in cfg.mk recursively, so break this dead-loop.
>
> Yes, I've run into this before; thanks for trying to tackle it.
>
>>
>> Signed-off-by: liguang <lig.fnst(a)cn.fujitsu.com>
>> ---
>> cfg.mk | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/cfg.mk b/cfg.mk
>> index bbfd4a2..92966d5 100644
>> --- a/cfg.mk
>> +++ b/cfg.mk
>> @@ -699,7 +699,7 @@ ifeq (0,$(MAKELEVEL))
>> test "$$stamp" = "$$actual"; echo $$?)
>> _clean_requested = $(filter %clean,$(MAKECMDGOALS))
>> ifeq (1,$(_update_required)$(_clean_requested))
>> - $(info INFO: gnulib update required; running ./autogen.sh first)
>> + $(error ERR: gnulib update required; running ./autogen.sh first)
>
> However, this is not the right fix - it will error out even when .gnulib
> is not dirty, but just out of date. I'll spend some time on this
> getting it right today.
Thanks again for forcing me to fix this; if you hadn't noticed, it was
fixed here:
https://www.redhat.com/archives/libvir-list/2012-October/msg00018.html
Good! pretty complex fix-up.
--
liguang lig.fnst(a)cn.fujitsu.com
FNST linux kernel team