Re: PG vs macOS Mojave

I wrote:
> Jakob Egger <jakob(at)eggerapps(dot)at> writes:
>> I would assume that clang sets -isysroot automatically, but I have no idea why that didn't work for you previously.

> [ experiments further ... ] It looks like clang does default to assuming
> -isysroot with the correct sysroot for its Xcode version. The missing bit
> of info is that -I /System/... is taken as an absolute path that's not
> affected by the sysroot. You have to write -iwithsysroot /System/...
> to have something that is taken relative to the sysroot.

> So as far as pltcl is concerned, we don't really need the configure
> hack to insert PG_SYSROOT into TCL_INCLUDE_SPEC; we could leave Apple's
> value alone and it should work. (Not that that gets pltcl out of
> dependency on the sysroot entirely, because AFAICS there's still no way
> to find tclConfig.sh without explicitly accounting for sysroot. And
> I'm not exactly convinced that using explicit sysroot to do that and
> then leaving it out later is a hot idea.)

> However, on the Perl side, we'd have to change -I to -iwithsysroot if
> we wanted to avoid explicitly mentioning the sysroot path, and that
> seems way more invasive than it's worth.

> I'm inclined to leave things as they stand now; it makes for reasonably
> consistent build behavior between pltcl and plperl.

After sleeping on it, I'm not really happy with that answer. I think
we'd be better advised to remove the hack on TCL_INCLUDE_SPEC, and
change what we've done for Perl to look more like what Tcl does.
That is, instead of writing "-I$(perl_includedir)/CORE" in Makefiles,
we should write "$(perl_includespec)" so that the switch spelling
is included in the variable. Then we'd make configure set that
variable to either "-I$perl_archlibexp/CORE" or
"-iwithsysroot $perl_archlibexp/CORE" depending on what it finds
to be needed. In this way, while we can't avoid knowing the sysroot
path explicitly during configure, we aren't wiring it into anything
that configure emits.

It would be a good idea to change this now, before the results of commit
5e2217131 spread too far in the wild, so that plperl-related extensions
only have to deal with one Makefile change not two.

(BTW, plpython is already doing it like this, meaning that it's plperl
that's the odd man out, not pltcl. It appears that Apple have not yet
sysroot-ified their Python installation, but it is not hard to see where
that train is going.)

regards, tom lane