Skip site navigation (1) Skip section navigation (2)

Re: Makefile for parser

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Chris Bitmead <chris(at)bitmead(dot)com>
Cc: Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Makefile for parser
Date: 2000-07-02 15:22:18
Message-ID: Pine.LNX.4.21.0007021316130.351-100000@localhost.localdomain (view raw or flat)
Thread:
Lists: pgsql-hackers
Chris Bitmead writes:

> Certainly the pgsql makefiles are broken for parallel make.

I think of "broken" for parallel make if it doesn't work at all, which
certainly needs to be fixed. "Unsupportive" of parallel make are things
like this:

DIRS := initdb initlocation ipcclean pg_ctl pg_dump pg_id \
        pg_passwd pg_version psql scripts

all:
        @for dir in $(DIRS); do $(MAKE) -C $$dir $@ || exit 1; done

because no matter how smart make is, the loop will still execute
sequentially.

But parallel make can co-exist with recursive make, like this:

DIRS := initdb initlocation ipcclean pg_ctl pg_dump pg_id \                       
        pg_passwd pg_version psql scripts

all: $(DIRS:%=%-all-recursive)

.PHONY: $(DIRS:%=%-all-recursive)

$(DIRS:%=%-all-recursive):
	$(MAKE) -C $(subst -all-recursive,,$@) all


Then again, if you want faster builds, use -pipe. I'd like to make that
the default but I haven't found a reliable way to test for it. GCC doesn't
reject invalid switches in a detectable manner.

-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e(at)gmx(dot)net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


In response to

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2000-07-02 15:22:43
Subject: Re: Big 7.1 open items
Previous:From: Peter EisentrautDate: 2000-07-02 15:21:56
Subject: Re: Makefile for parser

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group