From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jakob Egger <jakob(at)eggerapps(dot)at> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: PG vs macOS Mojave |
Date: | 2018-10-16 14:02:03 |
Message-ID: | 29535.1539698523@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jakob Egger <jakob(at)eggerapps(dot)at> writes:
> Am 25. Sep. 2018 um 06:49 schrieb Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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?
The concerns that strike my mind are mainly around the hazard that
configure's choices could be inappropriate for a build with a
different SDK. Given that, though, wiring -isysroot into the
configure output doesn't seem all that insane.
It's possible that we could arrange things so that the generated
Makefile.global looks like
PG_SYSROOT = /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
CPPFLAGS = -isysroot $(PG_SYSROOT)
instead of
CPPFLAGS = -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
thus making it a bit simpler to override that path at build time.
But I'm not sure that that really moves the goalposts very far for you
in terms of ease-of-use, and anyway it might just be greasing the skids
to a non-working extension.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2018-10-16 14:06:11 | Re: Creating Certificates |
Previous Message | Amit Kapila | 2018-10-16 13:05:28 | Re: WIP: Avoid creation of the free space map for small tables |