Thread: [PATCH] parallel & isolated makefile for plpython

[PATCH] parallel & isolated makefile for plpython

From
Pavel Raiskup
Date:
Hi, we observed issues with parallel make during RPM build in plpython,
seems like the attached patch 0002 should help.  Feel free to reject 0001,
but comment like that would save some time to me as a "newcomer" into that
Makefile.

Pavel

Attachment

Re: [PATCH] parallel & isolated makefile for plpython

From
Tom Lane
Date:
Pavel Raiskup <praiskup@redhat.com> writes:
> Hi, we observed issues with parallel make during RPM build in plpython,
> seems like the attached patch 0002 should help.  Feel free to reject 0001,
> but comment like that would save some time to me as a "newcomer" into that
> Makefile.

Hi Pavel!

> The submake-generated-headers can't be used as 'all' prerequisite
> at the same level with with 'all-lib', because
> 'submake-generated-headers' is actually prerequisite for
> 'all-libs' in this makefile.  So use submake-generated-headers as
> $(OBJS) prerequisite, as several object files depend on it.

D'oh.  This is my fault, IIRC.  Will fix.

> Move the 'all' target before include statement, according to
> documentation in Makefile.shlib.

Hm, actually that's unnecessary because Makefile.global already
established 'all' as the default target.  I'm inclined to think
that the comment in Makefile.shlib is wrong and should be removed
or at least rewritten, because I doubt it would work at all to
include Makefile.shlib before Makefile.global; certainly that's
not the intended usage.

> ! # gram.y=>gram.c.  Run `info make -n "Empty Recipes"` for more info. 
I'm okay with pointing people at that part of the gmake docs, but don't
care for insisting on exactly one way of accessing those docs.  How
about something like "... See "Empty Recipes" in the GNU Make docs for
more info."?

[ checks around... ]  Wait, actually there's a bigger problem: this
advice is apparently gmake-version-specific.  I don't see any
such section title in RHEL6's version of the gmake docs (make 3.81).
I do find a section titled "Using Empty Commands", which looks like
it might be the same thing, but a person looking for "Empty Recipes" is
not going to find that.  Is it worth the trouble to provide this pointer
if we need a lot of weasel wording about how the section name is spelled?
        regards, tom lane



Re: [PATCH] parallel & isolated makefile for plpython

From
Pavel Raiskup
Date:
Hi Tom,

On Saturday, October 1, 2016 12:23:03 PM CEST Tom Lane wrote:
> Hm, actually that's unnecessary because Makefile.global already
> established 'all' as the default target.  I'm inclined to think
> that the comment in Makefile.shlib is wrong and should be removed
> or at least rewritten, because I doubt it would work at all to
> include Makefile.shlib before Makefile.global; certainly that's
> not the intended usage.

correct analysis, the patch in git fixing this is also correct.  Thanks!

> > ! # gram.y=>gram.c.  Run `info make -n "Empty Recipes"` for more info.
>   
> I'm okay with pointing people at that part of the gmake docs, but don't
> care for insisting on exactly one way of accessing those docs.  How
> about something like "... See "Empty Recipes" in the GNU Make docs for
> more info."?
> 
> [ checks around... ]  Wait, actually there's a bigger problem: this
> advice is apparently gmake-version-specific.  I don't see any
> such section title in RHEL6's version of the gmake docs (make 3.81).
> I do find a section titled "Using Empty Commands", which looks like
> it might be the same thing, but a person looking for "Empty Recipes" is
> not going to find that.  Is it worth the trouble to provide this pointer
> if we need a lot of weasel wording about how the section name is spelled?

Valid points.  Let's forget about that patch.  I like pointing people to use
'info' directly instead of googling for link, but PostgreSQL docs is not a
correct place for this.

To the point; I was confused by two things.  First that (a) docs claim that
there is no _correct_ (instead of probably? _portable_) way to write one
rule for two "targets" and (b) that the comment for ';' ("The semicolon is
important, otherwise make will choose the built-in rule for ...") looked
too magically (without actually saying what it does).  I wrongly
concentrated on (b) only before.

First suggestion would be something towards:
 -# There is no correct way to write a rule that generates two files. +# This is a way to write a rule (for 'gram.c')
thatgenerates two files.
 

And the second:
 -# make, we must chain the dependencies like this.  The semicolon is -# important, otherwise make will choose the
built-inrule for -# gram.y=>gram.c. +# make, we must chain the dependencies like this.  The semicolon (Empty +#
Command/Recipe)is important, otherwise make will choose the built-in +# rule for gram.y=>gram.c.
 

FTR, also note that something like this could work:
 all: xxx.c xxx.h xxx%c xxx%h: xxx.txt       touch xxx.c xxx.h # info make -n "Pattern Intro", grep for 'multiple
targets'

But note that we don't have iterate here at all, because probably that was
just my problem (having a look at make docs resolved it ...).

Thanks again for the fix in git!

Pavel