Fix builds with --parallel

Python 3.5's distutils added support for parallel builds, which means
that we don't need to monkeypatch it anymore. But more importantly, this
monkeypatch made build fail (hang in fact) whenever `--parallel` was
passed to `python setup.py build`.

This commit fixes the problem by not applying the monkeypatch on
python 3.5+ and preserve the old behavior (parallel build by default) by
injecting a `parallel` option when it's not specified.

Author: Virgil Dupras

mp_compile.py

@@ -1,5 +1,7 @@
 # A monkey patch of the base distutils.ccompiler to use parallel builds
 # Tested on 2.7, looks to be identical to 3.3.
+# Only applied on Python < 3.5 because otherwise, it conflicts with Python's
+# own newly-added support for parallel builds.
 
 from __future__ import print_function
 from multiprocessing import Pool, cpu_count
@@ -77,4 +79,6 @@ def install():
               "%s processes" % MAX_PROCS)
 
 
-install()
+# We monkeypatch only versions earlier than 3.5
+if sys.version_info < (3, 5):
+    install()

setup.py

@@ -205,6 +205,12 @@ def finalize_options(self):
         if self.debug:
             global DEBUG
             DEBUG = True
+        if sys.version_info >= (3, 5) and not self.parallel:
+            # For Python < 3.5, we monkeypatch distutils to have parallel
+            # builds. If --parallel (or -j) wasn't specified, we want to
+            # reproduce the same behavior as before, that is, auto-detect the
+            # number of jobs.
+            self.parallel = mp_compile.MAX_PROCS
         for x in self.feature:
             if getattr(self, 'disable_%s' % x):
                 setattr(self.feature, x, False)