Refer to OS X as "macOS", except for the port name which is still "darwin".

We weren't terribly consistent about whether to call Apple's OS "OS X"
or "Mac OS X", and the former is probably confusing to people who aren't
Apple users.  Now that Apple has rebranded it "macOS", follow their lead
to establish a consistent naming pattern.  Also, avoid the use of the
ancient project name "Darwin", except as the port code name which does not
seem desirable to change.  (In short, this patch touches documentation and
comments, but no actual code.)

I didn't touch contrib/start-scripts/osx/, either.  I suspect those are
obsolete and due for a rewrite, anyway.

I dithered about whether to apply this edit to old release notes, but
those were responsible for quite a lot of the inconsistencies, so I ended
up changing them too.  Anyway, Apple's being ahistorical about this,
so why shouldn't we be?

1 files changed, 6 insertions, 6 deletions

diff --git a/configure.in b/configure.in
index 96d865de9f..9850d993ff 100644
--- a/configure.in
+++ b/configure.in
@@ -943,9 +943,9 @@ if test "$with_python" = yes; then
 
   if test "$python_enable_shared" != 1; then
     if test "$PORTNAME" = darwin; then
-      # OS X does supply a .dylib even though Py_ENABLE_SHARED does
+      # macOS does supply a .dylib even though Py_ENABLE_SHARED does
       # not get set.  The file detection logic below doesn't succeed
-      # on older OS X versions, so make it explicit.
+      # on older macOS versions, so make it explicit.
       python_enable_shared=1
     elif test "$PORTNAME" = win32; then
       # Windows also needs an explicit override.
@@ -1182,7 +1182,7 @@ if test "$with_uuid" = bsd ; then
     [UUID_LIBS=""],
     [AC_MSG_ERROR([BSD UUID functions are not present])])
 elif test "$with_uuid" = e2fs ; then
-  # On OS X, the UUID functions are in libc
+  # On macOS, the UUID functions are in libc
   AC_CHECK_FUNC(uuid_generate,
     [UUID_LIBS=""],
     [AC_CHECK_LIB(uuid, uuid_generate,
@@ -1425,8 +1425,8 @@ esac
 if test "$PORTNAME" != "win32"; then
    AC_SYS_LARGEFILE
    dnl Autoconf 2.69's AC_SYS_LARGEFILE believes it's a good idea to #define
-   dnl _DARWIN_USE_64_BIT_INODE, but it isn't: on OS X 10.5 that activates a
-   dnl bug that causes readdir() to sometimes return EINVAL.  On later OS X
+   dnl _DARWIN_USE_64_BIT_INODE, but it isn't: on macOS 10.5 that activates a
+   dnl bug that causes readdir() to sometimes return EINVAL.  On later macOS
    dnl versions where the feature actually works, it's on by default anyway.
    AH_VERBATIM([_DARWIN_USE_64_BIT_INODE],[])
 fi
@@ -1479,7 +1479,7 @@ fi
 
 AC_CHECK_DECLS(fdatasync, [], [], [#include <unistd.h>])
 AC_CHECK_DECLS([strlcat, strlcpy])
-# This is probably only present on Darwin, but may as well check always
+# This is probably only present on macOS, but may as well check always
 AC_CHECK_DECLS(F_FULLFSYNC, [], [], [#include <fcntl.h>])
 
 HAVE_IPV6=no