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