Re: [PATCH] parallel & isolated makefile for plpython - Mailing list pgsql-hackers

From Pavel Raiskup
Subject Re: [PATCH] parallel & isolated makefile for plpython
Date
Msg-id 12195724.BIpmHemAye@unused-4-107.brq.redhat.com
Whole thread Raw
In response to Re: [PATCH] parallel & isolated makefile for plpython  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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




pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: PATCH: two slab-like memory allocators
Next
From: Peter Geoghegan
Date:
Subject: Re: On conflict update & hint bits