Re: [PATCH] parallel & isolated makefile for plpython

From: Pavel Raiskup <praiskup(at)redhat(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] parallel & isolated makefile for plpython
Date: 2016-10-02 05:24:51
Message-ID: 12195724.BIpmHemAye@unused-4-107.brq.redhat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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') that generates two files.

And the second:

-# make, we must chain the dependencies like this. The semicolon is
-# important, otherwise make will choose the built-in rule 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2016-10-02 08:36:22 Re: On conflict update & hint bits
Previous Message Tomas Vondra 2016-10-02 01:15:40 Re: PATCH: two slab-like memory allocators