Re: Makefiles don't seem to remember to rebuild everything anymore

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: cedric(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Makefiles don't seem to remember to rebuild everything anymore
Date: 2012-12-17 18:34:52
Message-ID: 28747.1355769292@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Now perhaps this is not make's fault so much as a lack of adequate
> dependency specifications. It may be that we can still use .SECONDARY
> if we add the $(OBJS) lists as explicit targets of "make all" in backend
> directories, but I'm not sure how invasive that would be.

I experimented a bit with this:

diff --git a/src/backend/common.mk b/src/backend/common.mk
index 2e56151..822b1e9 100644
*** a/src/backend/common.mk
--- b/src/backend/common.mk
*************** SUBDIROBJS = $(SUBDIRS:%=%/$(subsysfilen
*** 20,26 ****

# top-level backend directory obviously has its own "all" target
ifneq ($(subdir), src/backend)
! all: $(subsysfilename)
endif

SUBSYS.o: $(SUBDIROBJS) $(OBJS)
--- 20,26 ----

# top-level backend directory obviously has its own "all" target
ifneq ($(subdir), src/backend)
! all: $(subsysfilename) $(OBJS)
endif

SUBSYS.o: $(SUBDIROBJS) $(OBJS)

which seems to fix the main issue, but it's still a bit wonky as far
as making objfiles.txt goes:

$ cd pgsql/src/backend/parser/
$ rm analyze.o
rm: remove regular file `analyze.o'? y
$ make
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -I. -I. -I../../../src/include -D_GNU_SOURCE -c -o analyze.o analyze.c
$ make
touch objfiles.txt
$ make
make: Nothing to be done for `all'.

This is definitely not per make's contract, either. I think maybe the
"Don't rebuild the list if only the OBJS have changed" hack in common.mk
is a brick or two shy of a load, but I don't know how to fix that.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-12-17 18:39:17 Re: XLByte* usage
Previous Message Andres Freund 2012-12-17 18:30:10 Re: XLByte* usage