[issue45743] Cleanup and simplify setup.py

[Ned Deily]

Ned Deily <nad at python.org> added the comment:

It seems to me that some (most?) of the macOS-specific workarounds in setup.py were added to make it easy to build with the system-provided copies of the third-party libraries, like zlib and sqlite3 and openssl. At least one of the workarounds, search_paths_first, became the default ld behavior since around macOS 10.6 (Xcode 4). So when building on more recent macOS systems, either the workarounds aren't necessary any more or the third-party library is no longer provided (like openssl) or is otherwise too old (like Tk) so that you can no longer rely on building with just using system-supplied libraries to have a useful Python on macOS. And, if you are building on very old systems (because of hardware requirements or whatever), in most cases, the versions of the system-supplied libraries are so old that you shouldn't be relying on them anyway. So I think that, for 3.11, we could take a stand and say that we no longer support building with specific system-supplied third-party libraries on macOS systems older than, say, macOS 10.9; IOW, you will need to supply your own copies of those libs on older systems. That's essentially the approach the MacPorts project has taken for years; they still support providing current Pythons on old versions of macOS but they also supply current version of the third-party libs, too.

And Christian's work here for 3.11 to move away from setup.py and use pkg-config to remove the guesswork on header and lib locations should make life easier for everyone. There is a small issue here in that macOS does not supply a built-in pkg-config but there are implementations available, if you are unable or unwilling to use open source distributors like MacPorts or Homebrew, including an actively-maintained permissive-licensed version with no build dependencies that seems to work on even macOS 10.6 (I didn't try anything older than that!): https://github.com/pkgconf/pkgconf.

Ronald, what do you think?  If this sounds reasonable, we could draw up a list of libs and document it somewhere in the 3.11 code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45743>
_______________________________________