Andres Freund <and...@anarazel.de> writes:
> On 2018-04-01 13:38:15 -0400, Tom Lane wrote:
>> I don't have a concrete patch to propose yet, but the design idea
>> I have in mind is to split LDFLAGS into two or more parts, so that
>> -L switches for the build tree are supposed to be put in the first
>> part and external -L switches in the second.
> I'm not sure I like doing this in Makefile.global. We've various files
> that extend LDFLAGS in other places, and that's going to be hard if it's
> already mushed together again. We end up re-building it from parts in
> those files too.
Yeah, one of the things I'd like to fix is that some of the makefiles,
eg psql's, do
override LDFLAGS := -L$(top_builddir)/src/fe_utils -lpgfeutils $(libpq_pgport)
$(LDFLAGS)
which goes *directly* against this commandment in Makefile.global:
# We want -L for libpgport.a and libpgcommon.a to be first in LDFLAGS. We
# also need LDFLAGS to be a "recursively expanded" variable, else adjustments
# to rpathdir don't work right. So we must NOT do LDFLAGS := something,
# meaning this has to be done first and elsewhere we must only do LDFLAGS +=
# something.
It's a bit surprising that rpath works at all for these makefiles.
But with what I'm imagining here, I think we could replace that with
LDFLAGS_INTERNAL += -L$(top_builddir)/src/fe_utils -lpgfeutils $(libpq_pgport)
and thereby preserve the recursively-expanded virginity of both
LDFLAGS_INTERNAL and LDFLAGS. But I've not tried to test anything yet.
> Why don't we change the link commands to reference LDFLAGS_INTERNAL
> explicitly? That seems like it'd be cleaner.
I'm hesitant to do that because LDFLAGS is a name known to make's
default rules, and I don't want to bet that we're not relying on
those default rules anywhere. I also disagree with the idea that using
"$(LDFLAGS_INTERNAL) $(LDFLAGS)" in every link command we have is better
or less error-prone than just "$(LDFLAGS)". Especially not if we end up
with more than two parts.
regards, tom lane
