On Tue, Mar 30, 2021 at 7:51 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Thomas Munro <thomas.munro@gmail.com> writes:
> > Personally I'm mostly concerned about making it easy for new
> > contributors to get a working dev system going on a super common
> > platform without dealing with hard-to-diagnose errors, than people who
> > actually want a different target as a deliberate choice. Do I
> > understand correctly that there a period of time each year when major
> > upgrades come out of sync and lots of people finish up running a
> > toolchain and OS with this problem for a while due to the default
> > target not matching? If so I wonder if other projects are running
> > into this with AC_REPLACE_FUNCS and what they're doing.
>
> Yeah, we've seen this happen at least a couple of times, though
> it was only during this past cycle that we (I anyway) entirely
> understood what was happening.
>
> The patches we committed in January (4823621db, 9d23c15a0, 50bebc1ae)
> to improve our PG_SYSROOT selection heuristics should theoretically
> improve the situation ... though I admit I won't have a lot of
> confidence in them till we've been through a couple more rounds of
> asynchronous-XCode-and-macOS releases. Still, I feel that we
> ought to leave that code alone until we see how it does.
I mean, we know that it will still break under a number of common
circumstances so I think we should be fixing the root cause(improper
detection of target deployment API availability in probes) in some
way as this will probably continue to be an issue otherwise, we already
know that improving PG_SYSROOT selection can not fix the root issue
but rather tries to workaround it in a way that is pretty much guaranteed
to be brittle.
Is there any approach to fixing the root cause of this issue that you think
would be acceptable?
>
> regards, tom lane
