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

From James Hilliard
Subject Re: [PATCH 1/1] Fix detection of pwritev support for OSX.
Date
Msg-id CADvTj4qDYCej1jCVLP7kDMxR31=nsDg4Oy6KZ6t-kxsVR_PUhA@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH 1/1] Fix detection of pwritev support for OSX.  (Sergey Shinderuk <s.shinderuk@postgrespro.ru>)
List pgsql-hackers
On Sat, Jan 23, 2021 at 1:27 AM Sergey Shinderuk
<s.shinderuk@postgrespro.ru> wrote:
>
> On 23.01.2021 08:02, Sergey Shinderuk wrote:
> >> On the whole it looks like we should recommend installing the CLT
> >> and not bothering with Xcode, which is about 10X the size:
> >>
> >> $ du -hs /Library/Developer/CommandLineTools
> >> 1.1G    /Library/Developer/CommandLineTools
> >> $ du -hs /Applications/Xcode.app
> >>   15G    /Applications/Xcode.app
> >>
> >
> > Fair.
>
> BTW, Homebrew prefers the CLT SDK:
> https://github.com/Homebrew/brew/blob/master/Library/Homebrew/os/mac.rb#L138
>
>        # Prefer CLT SDK when both Xcode and the CLT are installed.
>        # Expected results:
>        # 1. On Xcode-only systems, return the Xcode SDK.
>        # 2. On Xcode-and-CLT systems where headers are provided by the
> system, return nil.
>        # 3. On CLT-only systems with no CLT SDK, return nil.
>        # 4. On CLT-only systems with a CLT SDK, where headers are
> provided by the system, return nil.
>        # 5. On CLT-only systems with a CLT SDK, where headers are not
> provided by the system, return the CLT SDK.
>
>
> Here is the relevant discussion:
> https://github.com/Homebrew/brew/pull/7134
>
> I like the example of Git compiled against the wrong
> LIBCURL_VERSION_NUM. Clearly, there are other issues with
> cross-compiling to a newer SDK, besides autoconf probes and weak imports.

From my understanding homebrew considers supporting deployment targets
other than that of the build host entirely out of scope, due to its
nature of being
a meta build system homebrew probably needs to sidestep package target
deployment bugs in this way as they are likely to be quite common. Homebrew
also has to ensure compatibility with the binary bottles. Homebrew handles
backwards compatibility largely by using host OS specific binaries, which is not
the typical way package binaries are distributed on OSX.

So it appears that their reasoning for doing this may not be directly applicable
to the situation we have with postgres as they have additional concerns. In
theory we should generally not have to worry about this much as long as target
deployment feature detection is functional as either SDK would generally work
for producing binaries that can run on the build host.

>
> --
> Sergey Shinderuk
> Postgres Professional: http://www.postgrespro.com
> The Russian Postgres Company



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: POC: postgres_fdw insert batching
Next
From: Pavel Stehule
Date:
Subject: Re: proposal: schema variables