Re: ecpg-related build failure with make 3.82 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: ecpg-related build failure with make 3.82
Date
Msg-id 27794.1319828542@sss.pgh.pa.us
Whole thread Raw
In response to Re: ecpg-related build failure with make 3.82  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Oct 28, 2011 at 1:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I tried to reproduce this on my own Fedora 14 box, and couldn't.
>> I cd'd to src/interfaces/ecpg/preproc and did several repetitions of
>> 
>>        make maintainer-clean
>>        make -j
>> 
>> and every time, make carefully waited until bison was done before
>> launching the compiles of preproc.o, parser.o, and the other files
>> that are declared to depend on preproc.h.

> I see the same thing.  But when I do make -j3 at the toplevel, it
> bombs out as described before.

In that case it's a make bug, which you should file with the proper
authorities.  I could believe it was our problem if it manifested when
starting from src/interfaces/ecpg, but none of the higher-level
makefiles know anything about subdirectories of ecpg.

>> I *can* reproduce failures if I do the same thing one directory level
>> up, in src/interfaces/ecpg.  But those are caused by the other sub-makes
>> not waiting for include/ecpg_config.h to get built.  Fixing that is
>> beyond my level of make-fu.

> I can also reproduce this problem.  I think this one does not occur on
> a fresh build because ecpg_config.h is created by configure and is
> only removed by make maintainer-clean.

Well, on closer inspection, running ecpg/include/Makefile is sufficient
to rebuild ecpg_config.h, apparently because of rules in
Makefile.global.  Now that I look at it, I bet we could fix that part
with some additions to the dependency rules in ecpg/Makefile.  But it
doesn't seem related at all to the preproc problem.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: So, is COUNT(*) fast now?
Next
From: Tom Lane
Date:
Subject: Re: So, is COUNT(*) fast now?