Instead of trying to convince setup.py to do what we want, the wheel
package empowers us to unpack and directly manipulate the wheel.
In particular this is important because `--skip-build` really does
not work.

First we build a native wheel. If skip_host is True, then this
"native" wheel has defective empty files as binaries, if it's False,
we build a real native wheel. If skip_host is False, then we use
pip to install our native wheel into host directory.

Then we unpack the wheel, replace the platform tag with
wasm32_emscripten, remove the non-metadata files, and copy in the
new files with the cross compiled binaries.

Of course, this is all only necessary for binary extensions.


Hopefully this will help get us towards using alternative build
backends. The one concern is that this approach depends on
implementation details of where the build backend puts the files
into the directory tree before copying them into the wheel. If
the build backend moved the linked binaries after building them,
we would be in trouble. Or worse if the build backend deleted the
files after packing them into the wheel, we'd be in trouble.

Basically, it seems clear that we can only support alternative
build backends on a case-by-case basis.

@henryiii I'm curious what your thoughts are cross compilation + arbitrary build backends.

Better package cross compilation. Instead of trying to convince setup.py to do what we want, the wheel
package empowers us to unpack and directly manipulate the wheel.
In particular this is important because `--skip-build` really does
not work.

First we build a native wheel. If skip_host is True, then this
"native" wheel has defective empty files as binaries, if it's False,
we build a real native wheel. If skip_host is False, then we use
pip to install our native wheel into host directory.

Then we unpack the wheel, replace the platform tag with
wasm32_emscripten, remove the non-metadata files, and copy in the
new files with the cross compiled binaries.

Of course, this is all only necessary for binary extensions.


Hopefully this will help get us towards using alternative build
backends. The one concern is that this approach depends on
implementation details of where the build backend puts the files
into the directory tree before copying them into the wheel. If
the build backend moved the linked binaries after building them,
we would be in trouble. Or worse if the build backend deleted the
files after packing them into the wheel, we'd be in trouble.

Basically, it seems clear that we can only support alternative
build backends on a case-by-case basis.

@henryiii I'm curious what your thoughts are cross compilation + arbitrary build backends.

commit 12b131883a0505987b052cb58ee1320aed24aeb4
Author: Roman Yurchak <rth.yurchak@gmail.com>
Date:   Mon Mar 22 21:33:26 2021 +0100

    Use float error status without external includes in numpy
    
    A better solution would be to rely on FE_DIVBYZERO, FE_DIVBYZERO etc
    defined in musl's fenv.h (https://github.com/numpy/numpy/pull/12124)
    however these are not valid for emscripten
    (https://github.com/emscripten-core/emscripten/issues/13678)

diff --git a/numpy/core/src/npymath/ieee754.c.src b/numpy/core/src/npymath/ieee754.c.src
index 3f66b24a4..6beb63edc 100644
--- a/numpy/core/src/npymath/ieee754.c.src
+++ b/numpy/core/src/npymath/ieee754.c.src
@@ -682,7 +682,8 @@ void npy_set_floatstatus_invalid(void)
 }
 
 #elif defined(_MSC_VER) || (defined(__osf__) && defined(__alpha)) || \
-      defined (__UCLIBC__) || (defined(__arc__) && defined(__GLIBC__))
+      defined (__UCLIBC__) || (defined(__arc__) && defined(__GLIBC__)) || \
+      defined(__EMSCRIPTEN__)
 
 /*
  * By using a volatile floating point value,
@@ -719,37 +720,22 @@ void npy_set_floatstatus_invalid(void)
 }
 
 /* MS Windows -----------------------------------------------------*/
-#if defined(_MSC_VER)
+#if defined(_MSC_VER) || defined(__EMSCRIPTEN__)
 
 #include <float.h>
 
 int npy_get_floatstatus_barrier(char *param)
 {
-    /*
-     * By using a volatile, the compiler cannot reorder this call
-     */
-#if defined(_WIN64)
-    int fpstatus = _statusfp();
-#else
-    /* windows enables sse on 32 bit, so check both flags */
-    int fpstatus, fpstatus2;
-    _statusfp2(&fpstatus, &fpstatus2);
-    fpstatus |= fpstatus2;
-#endif
-    if (param != NULL) {
-        volatile char NPY_UNUSED(c) = *(char*)param;
-    }
-    return ((SW_ZERODIVIDE & fpstatus) ? NPY_FPE_DIVIDEBYZERO : 0) |
-           ((SW_OVERFLOW & fpstatus) ? NPY_FPE_OVERFLOW : 0) |
-           ((SW_UNDERFLOW & fpstatus) ? NPY_FPE_UNDERFLOW : 0) |
-           ((SW_INVALID & fpstatus) ? NPY_FPE_INVALID : 0);
+   /* 
+   TODO: This is a suboptimal implementation from numpy 1.15.4 that would lead
+   to issues like https://github.com/numpy/numpy/issues/12095 
+   */
+   return 0;
 }
 
 int npy_clear_floatstatus_barrier(char *param)
 {
     int fpstatus = npy_get_floatstatus_barrier(param);
-    _clearfp();
-
     return fpstatus;
 }
 

commit 12b131883a0505987b052cb58ee1320aed24aeb4
Author: Roman Yurchak <rth.yurchak@gmail.com>
Date:   Mon Mar 22 21:33:26 2021 +0100

    Use float error status without external includes in numpy
    
    A better solution would be to rely on FE_DIVBYZERO, FE_DIVBYZERO etc
    defined in musl's fenv.h (https://github.com/numpy/numpy/pull/12124)
    however these are not valid for emscripten
    (https://github.com/emscripten-core/emscripten/issues/13678)

diff --git a/numpy/core/src/npymath/ieee754.c.src b/numpy/core/src/npymath/ieee754.c.src
index 3f66b24a4..6beb63edc 100644
--- a/numpy/core/src/npymath/ieee754.c.src
+++ b/numpy/core/src/npymath/ieee754.c.src
@@ -682,7 +682,8 @@ void npy_set_floatstatus_invalid(void)
 }
 
 #elif defined(_MSC_VER) || (defined(__osf__) && defined(__alpha)) || \
-      defined (__UCLIBC__) || (defined(__arc__) && defined(__GLIBC__))
+      defined (__UCLIBC__) || (defined(__arc__) && defined(__GLIBC__)) || \
+      defined(__EMSCRIPTEN__)
 
 /*
  * By using a volatile floating point value,
@@ -719,37 +720,22 @@ void npy_set_floatstatus_invalid(void)
 }
 
 /* MS Windows -----------------------------------------------------*/
-#if defined(_MSC_VER)
+#if defined(_MSC_VER) || defined(__EMSCRIPTEN__)
 
 #include <float.h>
 
 int npy_get_floatstatus_barrier(char *param)
 {
-    /*
-     * By using a volatile, the compiler cannot reorder this call
-     */
-#if defined(_WIN64)
-    int fpstatus = _statusfp();
-#else
-    /* windows enables sse on 32 bit, so check both flags */
-    int fpstatus, fpstatus2;
-    _statusfp2(&fpstatus, &fpstatus2);
-    fpstatus |= fpstatus2;
-#endif
-    if (param != NULL) {
-        volatile char NPY_UNUSED(c) = *(char*)param;
-    }
-    return ((SW_ZERODIVIDE & fpstatus) ? NPY_FPE_DIVIDEBYZERO : 0) |
-           ((SW_OVERFLOW & fpstatus) ? NPY_FPE_OVERFLOW : 0) |
-           ((SW_UNDERFLOW & fpstatus) ? NPY_FPE_UNDERFLOW : 0) |
-           ((SW_INVALID & fpstatus) ? NPY_FPE_INVALID : 0);
+   /* 
+   TODO: This is a suboptimal implementation from numpy 1.15.4 that would lead
+   to issues like https://github.com/numpy/numpy/issues/12095 
+   */
+   return 0;
 }
 
 int npy_clear_floatstatus_barrier(char *param)
 {
     int fpstatus = npy_get_floatstatus_barrier(param);
-    _clearfp();
-
     return fpstatus;
 }
 
