Re: [PATCH 1/1] Fix detection of pwritev support for OSX. - Mailing list pgsql-hackers

On Thu, Jan 21, 2021 at 11:38 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> James Hilliard <james.hilliard1@gmail.com> writes:
> > On Wed, Jan 20, 2021 at 4:07 PM Tom Lane <tgl@sss.pgh.pa.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/