Re: [PATCH 1/1] Fix detection of pwritev support for OSX.

On Thu, Jan 21, 2021 at 11:38 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> James Hilliard <james(dot)hilliard1(at)gmail(dot)com> writes:
> > On Wed, Jan 20, 2021 at 4:07 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> I'm not sure that the case of not having the "command line tools"
> >> installed is interesting for our purposes. AFAIK you have to have
> >> that in order to have access to required tools like bison and gmake.
> >> (That reminds me, I was intending to add something to our docs
> >> about how-to-build-from-source to say that you need to install those.)
>
> > Yeah, not 100% sure but I was able to build just fine after deleting my
> > command line tools.
>
> Hm. I've never been totally clear on what's included in the "command line
> tools", although it's now apparent that one thing that gets installed is
> an SDK matching the host OS version. However, Apple's description at [1]
> says
>
> Command Line Tools
>
> Download the macOS SDK, headers, and build tools such as the Apple
> LLVM compiler and Make. These tools make it easy to install open
> source software or develop on UNIX within Terminal. macOS can
> automatically download these tools the first time you try to build
> software, and they are available on the downloads page.
>
> which certainly strongly implies that gmake is not there otherwise.
> At this point I lack any "bare" macOS system to check it on. I wonder
> whether you have a copy of make available from MacPorts or Homebrew.
> Or maybe uninstalling the command line tools doesn't really remove
> everything?
>
> > It would be pretty annoying to have to install an outdated SDK just to
> > build postgres for no other reason than the autoconf feature detection
> > being broken.
>
> It's only as "outdated" as your host system ;-). Besides, it doesn't
> look like Apple's really giving you a choice not to.
>
> The long and short of this is that I'm unwilling to buy into maintaining
> our own substitutes for standard autoconf probes in order to make it
> possible to use the wrong SDK version. The preadv/pwritev case is already
> messy enough, and I fear that trying to support such scenarios is going to
> lead to more and more pain in the future.

I found a cleaner alternative to the compile test that appears to work:
https://postgr.es/m/20210122193230.25295-1-james.hilliard1%40gmail.com

Best I can tell the target deployment version check logic requires that the
<sys/uio.h> header be included in order for the check to function properly.

It seems we just need to avoid AC_REPLACE_FUNCS for these cases since
it doesn't allow for passing headers.

>
> regards, tom lane
>
> [1] https://developer.apple.com/xcode/features/