Re: Fixing parallel make of libpq

Tom Lane <[email protected]> writes:

> My thoughts about the patch:
>
> 1) Changing from an "|"-style dependency to a plain dependency seems
> like a semantics change.  I've never been totally clear on the
> difference though.  I think Peter introduced our use of the "|" style,
> so maybe he can comment.

Makefile.shlib puts $(SHLIB_PREREQS) after the "|":

$ grep SHLIB_PREREQS src/Makefile.shlib
# SHLIB_PREREQS         Order-only prerequisites for library build target
$(stlib): $(OBJS) | $(SHLIB_PREREQS)
$(shlib): $(OBJS) | $(SHLIB_PREREQS)
$(shlib): $(OBJS) | $(SHLIB_PREREQS)
$(shlib): $(OBJS) | $(SHLIB_PREREQS)
$(shlib): $(OBJS) | $(SHLIB_PREREQS)
$(shlib): $(OBJS) $(DLL_DEFFILE) | $(SHLIB_PREREQS)


> 2) The same coding pattern is used in a bunch of other places, so if
> this spot is broken, there probably are a lot of others that need a
> similar change.  On the other hand, there may not be that many
> directories that are likely places to start a parallel build from,
> so maybe we don't care elsewhere.

Grepping the Makefiles for ':.*submake-' shows that they are on the
actual build artifact target, libpq was just the outlier having it on
the phony "all" target.  For example pg_basebackup:

pg_basebackup: pg_basebackup.o $(OBJS) | submake-libpq submake-libpgport submake-libpgfeutils
               $(CC) $(CFLAGS) pg_basebackup.o $(OBJS) $(LDFLAGS) $(LDFLAGS_EX) $(LIBS) -o $@$(X)

pg_receivewal: pg_receivewal.o $(OBJS) | submake-libpq submake-libpgport submake-libpgfeutils
               $(CC) $(CFLAGS) pg_receivewal.o $(OBJS) $(LDFLAGS) $(LDFLAGS_EX) $(LIBS) -o $@$(X)

pg_recvlogical: pg_recvlogical.o $(OBJS) | submake-libpq submake-libpgport submake-libpgfeutils
               $(CC) $(CFLAGS) pg_recvlogical.o $(OBJS) $(LDFLAGS) $(LDFLAGS_EX) $(LIBS) -o $@$(X)

- ilmari
-- 
"A disappointingly low fraction of the human race is,
 at any given time, on fire." - Stig Sandbeck Mathisen