Re: changes in pgport etc doesn't cause client programs to be relinked

Hi,

On 2021-10-26 11:04:54 -0700, Andres Freund wrote:
> pgbench: $(OBJS) | submake-libpq submake-libpgport submake-libpgfeutils
> $(CC) $(CFLAGS) $^ $(LDFLAGS) $(LDFLAGS_EX) $(LIBS) -o $(at)$(X)

> I unfortunately don't see a localized fix for this. Afaict we'd need to change
> all client build rules to also have a dependency on the library?

For a second I thought I had an elegant solution to this: Many linkers these
days support --dependency-file, similar to the way we deal with dependencies
for compilation.

But that doesn't work easily either, because we use $^ in at least some of the
recipes for building executables. Which will contain the generated library
dependencies after the first build. That's easy enough to fix for things like
pgbench, where $^ is used directly, but there's also some binaries that we
build using prefix rules.

Like

# Replace gmake's default rule for linking a single .o file to produce an
# executable. The main point here is to put LDFLAGS after the .o file,
# since we put -l switches into LDFLAGS and those are order-sensitive.
# In addition, include CFLAGS and LDFLAGS_EX per project conventions.
%: %.o
$(CC) $(CFLAGS) $^ $(LDFLAGS) $(LDFLAGS_EX) $(LIBS) -o $(at)$(X)

which, despite the comment, we not just use with a single object file, but
also with multiple ones, afaict. E.g. in src/bin/scripts/Makefile. With a
single object file we could just replace $^ with $(at)(dot)o, but...

Of course we could filter $^ to only contain .o's, but at some point this
isn't a simple solution anymore :(

Greetings,

Andres Freund