Repository: netket/netket

Issue:
Compiling with USE_LAPACK in v2.0 is broken 
Reported by @fabienalet 


Discussion:
I think it's related to [this](https://github.com/libigl/libigl/issues/651).
The simplest workaround I found seems to 
````
#undef I
````
before
````
#include "Dynamics/pydynamics.hpp"
````
in [pynetket.cc](https://github.com/netket/netket/blob/v2.0/NetKet/pynetket.cc)
It compiles but it's a bit ugly and I'm not sure if it won't break other things later.
Oh interesting, I thought we had already solved this before! I personally changed all the `I` to `Iu` in a lot of parts in the code. Maybe there is some leftover. In what part of the code do we still have `I` ? Maybe it's easier just to rename those and not use the `#undef` 
It is in pybind11 actually. More precisely [here](https://github.com/pybind/pybind11/blob/a23996fce38ff6ccfbcdc09f1e63f2c4be5ea2ef/include/pybind11/detail/common.h#L473) and perhaps elsewhere
Oh I see, then we should open an issue on pybind11 
The thing is that whenever one loads <complex.h> pybind11 is unusable... this is definitely something they should be informed about 
@fabienalet and @gcarleo pybind11 is not the one to blame here! It's basically standard practice in template-heavy C++ code to use `Is` or `I` for integral parameter/parameter packs. Most style guides mandate that template parameters must be in CamelCase and normal code's `i` is thus transformed into `I`.
Not to sound harsh, but anyone who includes `<complex.h>` in C++ code is most likely doing something very wrong. Including `<complex.h>` is really just asking for trouble :)
So if anything, I'd submit a bug report to Eigen which includes it in one of the low-level cblas-related parts and doesn't undefine the macros afterwards.
@twesterhout I wonder wether with separate compilation we can also fix this old issue ? 
I can give it a try.

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -58,6 +58,29 @@ def __init__(self, name, sourcedir=""):
         self.sourcedir = os.path.abspath(sourcedir)
 
 
+def _have_ninja():
+    """
+    Returns `True` if the [ninja](https://ninja-build.org/) build system is
+    available on the system.
+    """
+    with open(os.devnull, "wb") as devnull:
+        try:
+            subprocess.check_call("ninja --version".split(), stdout=devnull)
+        except OSError:
+            return False
+        else:
+            return True
+
+
+def _generator_specified(args):
+    """
+    Returns `True` if `-G` flag was given to CMake.
+    """
+    for _ in filter(lambda f: f.startswith("-G"), args):
+        return True
+    return False
+
+
 class CMakeBuild(build_ext):
     """
     We extend setuptools to support building extensions with CMake. An extension
@@ -82,6 +105,8 @@ def build_extension(self, ext):
                 "-DNETKET_PYTHON_VERSION={}.{}.{}".format(*sys.version_info[:3])
             )
             cmake_args.append("-DCMAKE_LIBRARY_OUTPUT_DIRECTORY={}".format(lib_dir))
+            if not _generator_specified(cmake_args) and _have_ninja():
+                cmake_args.append("-GNinja")
 
             def _decode(x):
                 if sys.version_info >= (3, 0):


Test patch: