Re: ecpg-related build failure with make 3.82

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: ecpg-related build failure with make 3.82
Date: 2011-10-28 19:02:22
Message-ID: 27794.1319828542@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Oct 28, 2011 at 1:24 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-10-28 19:27:36 Re: So, is COUNT(*) fast now?
Previous Message Robert Haas 2011-10-28 18:51:28 Re: So, is COUNT(*) fast now?