I wrote:
> Jakob Egger <jakob@eggerapps.at> writes:
>> Am 25. Sep. 2018 um 06:49 schrieb Tom Lane <tgl@sss.pgh.pa.us>:
>>> It's a bit scary to be adding -isysroot globally.
>> This breaks building extensions with a different SDK than the server itself.
> Hm, under what circumstances would that be safe or a good idea?
Oh, well *this* is interesting. I stated at the top of this thread that
pltcl doesn't build on Mojave without -isysroot because TCL_INCLUDE_SPEC
gets set to
-iwithsysroot /System/Library/Frameworks/Tcl.framework/Versions/8.5/Headers
I wondered how messy it would be to translate that to a plain -I spec,
and along the way I found out that we apparently don't have to. If I do
nothing except remove -isysroot from CPPFLAGS, Apple's clang seems to
still find tcl.h at
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/Tcl.framework/Versions/8.5/Headers/tcl.h
Now, I would swear that I tested that before, and it didn't work;
but I think I might have been testing the combination of Xcode 10 on
High Sierra. It definitely works with Xcode 10 on Mojave. I no longer
have a High Sierra installation to recheck the original observation on.
However, it also works for me if I change "-isysroot /..." to
"-I $(PG_SYSROOT)/...", and that seems like on the whole it'd be the
safest solution across different compilers and version combinations.
If we go this route, then the configure-time sysroot path will get
embedded into $perl_includedir and $TCL_INCLUDE_SPEC, but noplace
else. I don't know how far that would improve your concern about
extensions, but it should help a little.
I'm still a bit dubious about the safety of building extensions
with different SDKs than the server, but if it worked for you
before then there's no reason for us to break it further than
we have to.
regards, tom lane