Removing all traces of 32-bit support for OS X.

Also updating `native-libraries.rst` to reflect more
recent changes.

The `scripts/osx/travis_journal.txt` file is temporarily
"empty" so that the build failure will give a full diff that
can be copy-pasted from Travis CI.

.gitignore

@@ -23,9 +23,6 @@ src/bezier/_speedup*.so
 wheelhouse/
 scripts/osx/dist_wheels/
 scripts/osx/fixed_wheels/
-scripts/osx/frankenstein/
-scripts/osx/tempdir-i386/
-scripts/osx/tempdir-x86_64/
 tests/fortran/*.gcda
 tests/fortran/*.gcno
 tests/fortran/*.o

DEVELOPMENT.rst

@@ -445,8 +445,8 @@ Python versions we test in. The image used in our CircleCI builds (from
 ``nox`` and NumPy).
 
 On Travis CI, Matthew Brett's `multibuild`_ is used to install "official"
-python.org CPython binaries for Mac OS X. Then tests are run in both 32-bit
-and 64-bit mode.
+python.org CPython binaries for Mac OS X. Then tests are run in both 64-bit
+mode (NumPy has `discontinued`_ 32-bit support).
 
 On AppVeyor, all extensions are built and tested with both 32-bit and 64-bit
 Python binaries.
@@ -460,6 +460,7 @@ Python binaries.
 .. _python-multi Dockerfile: https://github.com/dhermes/python-multi/blob/master/src/Dockerfile
 .. _bezier Dockerfile: https://github.com/dhermes/bezier/blob/master/scripts/docker/bezier.Dockerfile
 .. _multibuild: https://github.com/matthew-brett/multibuild
+.. _discontinued: https://github.com/numpy/numpy/issues/11625
 
 ****************************************
 Release Process / Deploying New Versions

DEVELOPMENT.rst.template

@@ -445,8 +445,8 @@ Python versions we test in. The image used in our CircleCI builds (from
 ``nox`` and NumPy).
 
 On Travis CI, Matthew Brett's `multibuild`_ is used to install "official"
-python.org CPython binaries for Mac OS X. Then tests are run in both 32-bit
-and 64-bit mode.
+python.org CPython binaries for Mac OS X. Then tests are run in both 64-bit
+mode (NumPy has `discontinued`_ 32-bit support).
 
 On AppVeyor, all extensions are built and tested with both 32-bit and 64-bit
 Python binaries.
@@ -460,6 +460,7 @@ Python binaries.
 .. _python-multi Dockerfile: https://github.com/dhermes/python-multi/blob/{revision}/src/Dockerfile
 .. _bezier Dockerfile: https://github.com/dhermes/bezier/blob/{revision}/scripts/docker/bezier.Dockerfile
 .. _multibuild: https://github.com/matthew-brett/multibuild
+.. _discontinued: https://github.com/numpy/numpy/issues/11625
 
 ****************************************
 Release Process / Deploying New Versions

docs/native-libraries.rst

@@ -4,8 +4,8 @@ Native Libraries
 
 .. note::
 
-   This content was last updated January 23, 2018 (as part of the
-   ``0.6.2`` release). Much of the content is tested automatically to keep
+   This content was last updated August 20, 2018 (as part of the
+   ``0.8.1`` release). Much of the content is tested automatically to keep
    from getting stale, but some of the console code blocks are not. As a
    result, this material may be out of date. If anything does not seem
    correct --- or even if the explanation is insufficient --- please
@@ -231,7 +231,7 @@ from a `Python wheel`_. The wheels uploaded to PyPI are pre-built, with
 Fortran extensions compiled with `GNU Fortran`_ (``gfortran``). As a
 result, ``libbezier`` will depend on ``libgfortran``. This can be problematic
 due to version conflicts, ABI incompatibility, a desire to use a different
-Fortran compiler (e.g. ``ifort``) and a host of other reasons.
+Fortran compiler (e.g. Intel's ``ifort``) and a host of other reasons.
 
 Some of the standard tooling for distributing wheels tries to address this. On
 Linux and Mac OS X, they address it by placing a copy of ``libgfortran`` (and
@@ -329,8 +329,8 @@ of ``libgfortran``:
            @loader_path/.dylibs/libgfortran.5.dylib (...)
            /usr/lib/libSystem.B.dylib (...)
 
-Though the Python extension modules (``.so`` files) only depend on
-``libgfortran``, they indirectly depend on ``libquadmath`` and
+Though the Python extension module (``.so`` file) only depends on
+``libgfortran``, it indirectly depends on ``libquadmath`` and
 ``libgcc_s``:
 
 .. doctest:: os-x-delocated-libgfortran
@@ -363,7 +363,7 @@ Windows
 =======
 
 A single Windows shared library (DLL) is provided: ``extra-dll/libbezier.dll``.
-The Python extension modules (``.pyd`` files) depend directly on this library:
+The Python extension module (``.pyd`` file) depends directly on this library:
 
 .. testsetup:: windows-extension, windows-dll
 
@@ -460,9 +460,8 @@ can happen:
     ``HeapFree``), so allocating memory with one and freeing with another is
     an error.
 
-This problem has been `largely fixed`_ in newer versions of
-Python but is still worth knowing, especially for older but still prominent
-Python 2.7.
+This problem has been `largely fixed`_ in newer versions of Python but is
+still worth knowing, especially for the older but still prominent Python 2.7.
 
 Unfortunately, there is no Fortran compiler provided by MSVC. The
 `MinGW-w64`_ suite of tools is a port of the GNU Compiler Collection (``gcc``)
@@ -507,6 +506,7 @@ on MinGW (at either compile, link or run time) is explicitly avoided. By adding
 the ``-static`` flag
 
 .. code-block:: console
+   :emphasize-lines: 2
 
    $ gfortran \
    >   -static \
@@ -544,7 +544,7 @@ on MinGW:
 
    Although ``msvcrt.dll`` is a dependency of ``libbezier.dll``, it is not
    a problem. Any values returned from Fortran (as ``intent(out)``) will
-   have already been allocated by the caller (e.g. the Python interpreter).
+   have already been allocated by the caller (e.g. the Python process).
    This won't necessarily be true for generic Fortran subroutines, but
    subroutines marked with ``bind(c)`` (i.e. marked as part of the C ABI
    of ``libbezier``) will not be allowed to use ``allocatable`` or
@@ -582,7 +582,7 @@ From there, an `import library`_ must be created
 
 .. _version of MSVC: http://matthew-brett.github.io/pydagogue/python_msvc.html
 .. _largely fixed: http://stevedower.id.au/blog/building-for-python-3-5-part-two/
-.. _MinGW-w64: https://mingw-w64.org
+.. _MinGW-w64: http://mingw-w64.org
 
 Source
 ======
@@ -594,7 +594,7 @@ depend on the local copy distributed with the ``bezier`` wheels.
 these libraries, if a different Fortran compiler is required or
 "just because".
 
-The Python extension modules (along with ``libbezier``) can be built from
+The Python extension module (along with ``libbezier``) can be built from
 source via:
 
 .. code-block:: console

docs/native-libraries.rst.template

@@ -4,8 +4,8 @@ Native Libraries
 
 .. note::
 
-   This content was last updated January 23, 2018 (as part of the
-   ``0.6.2`` release). Much of the content is tested automatically to keep
+   This content was last updated August 20, 2018 (as part of the
+   ``0.8.1`` release). Much of the content is tested automatically to keep
    from getting stale, but some of the console code blocks are not. As a
    result, this material may be out of date. If anything does not seem
    correct --- or even if the explanation is insufficient --- please
@@ -231,7 +231,7 @@ from a `Python wheel`_. The wheels uploaded to PyPI are pre-built, with
 Fortran extensions compiled with `GNU Fortran`_ (``gfortran``). As a
 result, ``libbezier`` will depend on ``libgfortran``. This can be problematic
 due to version conflicts, ABI incompatibility, a desire to use a different
-Fortran compiler (e.g. ``ifort``) and a host of other reasons.
+Fortran compiler (e.g. Intel's ``ifort``) and a host of other reasons.
 
 Some of the standard tooling for distributing wheels tries to address this. On
 Linux and Mac OS X, they address it by placing a copy of ``libgfortran`` (and
@@ -329,8 +329,8 @@ of ``libgfortran``:
            @loader_path/.dylibs/libgfortran.5.dylib (...)
            /usr/lib/libSystem.B.dylib (...)
 
-Though the Python extension modules (``.so`` files) only depend on
-``libgfortran``, they indirectly depend on ``libquadmath`` and
+Though the Python extension module (``.so`` file) only depends on
+``libgfortran``, it indirectly depends on ``libquadmath`` and
 ``libgcc_s``:
 
 .. doctest:: os-x-delocated-libgfortran
@@ -363,7 +363,7 @@ Windows
 =======
 
 A single Windows shared library (DLL) is provided: ``extra-dll/libbezier.dll``.
-The Python extension modules (``.pyd`` files) depend directly on this library:
+The Python extension module (``.pyd`` file) depends directly on this library:
 
 .. testsetup:: windows-extension, windows-dll
 
@@ -460,9 +460,8 @@ can happen:
     ``HeapFree``), so allocating memory with one and freeing with another is
     an error.
 
-This problem has been `largely fixed`_ in newer versions of
-Python but is still worth knowing, especially for older but still prominent
-Python 2.7.
+This problem has been `largely fixed`_ in newer versions of Python but is
+still worth knowing, especially for the older but still prominent Python 2.7.
 
 Unfortunately, there is no Fortran compiler provided by MSVC. The
 `MinGW-w64`_ suite of tools is a port of the GNU Compiler Collection (``gcc``)
@@ -507,6 +506,7 @@ on MinGW (at either compile, link or run time) is explicitly avoided. By adding
 the ``-static`` flag
 
 .. code-block:: console
+   :emphasize-lines: 2
 
    $ gfortran \
    >   -static \
@@ -544,7 +544,7 @@ on MinGW:
 
    Although ``msvcrt.dll`` is a dependency of ``libbezier.dll``, it is not
    a problem. Any values returned from Fortran (as ``intent(out)``) will
-   have already been allocated by the caller (e.g. the Python interpreter).
+   have already been allocated by the caller (e.g. the Python process).
    This won't necessarily be true for generic Fortran subroutines, but
    subroutines marked with ``bind(c)`` (i.e. marked as part of the C ABI
    of ``libbezier``) will not be allowed to use ``allocatable`` or
@@ -582,7 +582,7 @@ From there, an `import library`_ must be created
 
 .. _version of MSVC: http://matthew-brett.github.io/pydagogue/python_msvc.html
 .. _largely fixed: http://stevedower.id.au/blog/building-for-python-3-5-part-two/
-.. _MinGW-w64: https://mingw-w64.org
+.. _MinGW-w64: http://mingw-w64.org
 
 Source
 ======
@@ -594,7 +594,7 @@ depend on the local copy distributed with the ``bezier`` wheels.
 these libraries, if a different Fortran compiler is required or
 "just because".
 
-The Python extension modules (along with ``libbezier``) can be built from
+The Python extension module (along with ``libbezier``) can be built from
 source via:
 
 .. code-block:: console

nox.py

@@ -370,9 +370,6 @@ def clean(session):
         get_path("scripts", "osx", "__pycache__"),
         get_path("scripts", "osx", "dist_wheels"),
         get_path("scripts", "osx", "fixed_wheels"),
-        get_path("scripts", "osx", "frankenstein"),
-        get_path("scripts", "osx", "tempdir-i386"),
-        get_path("scripts", "osx", "tempdir-x86_64"),
         get_path("src", "bezier.egg-info"),
         get_path("src", "bezier", "__pycache__"),
         get_path("src", "bezier", "extra-dll"),

scripts/osx/build-wheels.sh

@@ -51,18 +51,13 @@ ${PY_BIN} -m pip install --upgrade delocate wheel virtualenv
 # Make sure install requirement are installed / up-to-date.
 ${PY_BIN} -m pip install --upgrade setuptools numpy
 
-# Make sure the custom ``libgfortran`` is in place.
-${PY_BIN} ${OSX_DIR}/make_universal_libgfortran.py
-
 # Indicate that wheels are being built.
 export BEZIER_WHEEL=True
 
-# Create the wheel (make sure to use the custom ``libgfortran``).
+# Create the wheel.
 DIST_WHEELS="${OSX_DIR}/dist_wheels"
 mkdir -p ${DIST_WHEELS}
-FRANKENSTEIN="${OSX_DIR}/frankenstein"
-GFORTRAN_LIB="${FRANKENSTEIN}" \
-    ${PY_BIN} -m pip wheel ${REPO_ROOT} \
+${PY_BIN} -m pip wheel ${REPO_ROOT} \
     --wheel-dir ${DIST_WHEELS}
 
 # Delocate the wheel.
@@ -87,13 +82,10 @@ ${VENV}/bin/python -m pip install \
     --find-links ${DIST_WHEELS}
 
 set +e  # Allow tests to fail
-# Run unit tests (in both 32 and 64 bit).
-arch -i386 ${VENV}/bin/py.test ${REPO_ROOT}/tests/unit
-arch -x86_64 ${VENV}/bin/py.test ${REPO_ROOT}/tests/unit
-# Run functional tests (in both 32 and 64 bit).
-arch -i386 ${VENV}/bin/py.test ${REPO_ROOT}/tests/functional
-arch -x86_64 ${VENV}/bin/py.test ${REPO_ROOT}/tests/functional
+# Run unit tests.
+${VENV}/bin/py.test ${REPO_ROOT}/tests/unit
+# Run functional tests.
+${VENV}/bin/py.test ${REPO_ROOT}/tests/functional
 
 # Clean-up.
 rm -fr ${VENV}
-rm -fr ${FRANKENSTEIN}

scripts/osx/local-test.sh

@@ -17,7 +17,6 @@
 # - checking that the "official" CPython is installed where expected
 # - checking that ``gfortran`` is installed
 # - setting of relevant environment variables
-# - building a universal ``libgfortran``
 # - make sure we have a latest `nox`, `pip`, `numpy` and `virtualenv`
 # - puts the "local" Python at the front of `PATH`
 
@@ -64,21 +63,6 @@ fi
 ${PY_BIN_DIR}/python -m pip install --upgrade virtualenv pip
 ${PY_BIN_DIR}/python -m pip install --upgrade 'nox-automation >= 0.19.1' numpy
 
-# Make sure there is a universal ``libgfortran``.
-export GFORTRAN_LIB="${OSX_SCRIPTS_DIR}/frankenstein"
-if [[ -d "${GFORTRAN_LIB}" ]]; then
-    echo "The 'frankenstein' universal gfortran library already exists."
-else
-    ${PY_BIN_DIR}/python ${OSX_SCRIPTS_DIR}/make_universal_libgfortran.py
-fi
-
-
-# Set up the tempfile directories for universal builds.
-export TEMPDIR_I386=${OSX_SCRIPTS_DIR}/tempdir-i386
-mkdir -p ${TEMPDIR_I386}
-export TEMPDIR_X86_64=${OSX_SCRIPTS_DIR}/tempdir-x86_64
-mkdir -p ${TEMPDIR_X86_64}
-
 # Make sure the current Python is at the front of `PATH`.
 export PATH="${PY_BIN_DIR}:${PATH}"