Re: PG vs macOS Mojave

> Am 1. Nov. 2018 um 04:17 schrieb Tom Lane <tgl@sss.pgh.pa.us>:
> 
> You can verify the thing's built-in settings with something like
> 
> $ echo >test.c
> $ clang -v -E test.c
> 
> and on Xcode 10.0 I get
> 
> "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.14.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -E -disable-free -disable-llvm-verifier -discard-value-names -main-file-name test.c -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -fno-strict-return -masm-verbose -munwind-tables -target-cpu penryn -dwarf-column-info -debugger-tuning=lldb -target-linker-version 409.12 -v -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -I/usr/local/include -fdebug-compilation-dir /Users/tgl -ferror-limit 19 -fmessage-length 80 -stack-protector 1 -fblocks -fencode-extended-block-signature -fobjc-runtime=macosx-10.14.0 -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o - -x c test.c
> 
> while with Xcode 10.1's compiler:
> 
> "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.14.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -E -disable-free -disable-llvm-verifier -discard-value-names -main-file-name test.c -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -fno-strict-return -masm-verbose -munwind-tables -target-cpu penryn -dwarf-column-info -debugger-tuning=lldb -target-linker-version 409.12 -v -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0 -fdebug-compilation-dir /Users/tgl -ferror-limit 19 -fmessage-length 80 -stack-protector 1 -fblocks -fencode-extended-block-signature -fobjc-runtime=macosx-10.14.0 -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o - -x c test.c
> 
> No default sysroot at all.  So the immediate question is whether Apple
> broke this in Xcode 10.1, or whether it was broken in Xcode 10.0 and
> now they've "fixed" it.

I've tried to replicate your experiment, but I initially got the "-isysroot" flag for both Xcode 10 and Xcode 10.1.

Then I upgraded the "Comand Line Tools for Xcode 10.1" using Software Update, and suddenly the "-isysroot" flag disappeared (for both Xcode 10 and Xcode 10.1).

In any case, it looks like we can't rely on "-isysroot" being present.


> Am 2. Nov. 2018 um 16:09 schrieb Tom Lane <tgl@sss.pgh.pa.us>:
> 
> Daniel Gustafsson <daniel@yesql.se <mailto:daniel@yesql.se>> writes:
>>> On 2 Nov 2018, at 15:42, Tom Lane <tgl@sss.pgh.pa.us <mailto:tgl@sss.pgh.pa.us>> wrote:
>>> Anybody have an opinion about which approach to use?  We need to choose
>>> one, and PDQ too, if we want full buildfarm coverage on it before Monday's
>>> wrap.
> 
>> #1 is the option that appeals to me the most, mostly because it removes all
>> possible ambiguity of when/if it’s required compared to #2.
> 
> I'm sort of leaning in that direction too, after sleeping on it.
> It's also closer to what we already shipped in 11.0 than #2 is.
> 
> 			regards, tom lane


I think I would prefer #2.

I think it would work better for my use case (end users download a binary of the server but may build their own extensions).


Regarding #1:
Since -isysroot is only necessary for building pl/tcl and pl/perl, why do you add it to CPPFLAGS in the global makefile?
Wouldn't it make more sense to just add it in the TCL and Perl makefiles?


Best regards,
Jakob