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.

package:
  name: numpy
  version: 1.21.4

source:
  url: https://files.pythonhosted.org/packages/fb/48/b0708ebd7718a8933f0d3937513ef8ef2f4f04529f1f66ca86d873043921/numpy-1.21.4.zip
  sha256: e6c76a87633aa3fa16614b61ccedfae45b91df2767cf097aa9c933932a7ed1e0

  patches:
    - patches/disable-maybe-uninitialized.patch
    - patches/dont-include-execinfo.patch
    - patches/fix-longdouble.patch
    - patches/fix-static-init-of-nditer-pywrap.patch
    - patches/init-alloc-cache.patch
    - patches/use-local-blas-lapack.patch
    - patches/fix-install-with-skip-build.patch
    - patches/make-int-return-values.patch
    - patches/fix-ieee754.patch
    - patches/disable-optimization.patch
    - patches/not-build-lapack-lite-as-64-bit.patch
    - patches/fix-invalid-asm-instruction.patch
    - patches/fix-comparator-function-signatures.patch
    - patches/fix-random_float_fill-return-type.patch

build:
  skip_host: False
  # set linker and C flags to error on anything to do with function declarations being wrong.
  # In webassembly, any conflicts mean that a randomly selected 50% of calls to the function
  # will fail. Better to fail at compile or link time.
  cflags: |
    -include math.h
    -I $(PYODIDE_ROOT)/packages/numpy/config
    -Werror=implicit-function-declaration
    -Werror=mismatched-parameter-types
    -Werror=mismatched-return-types
  ldflags: |
    -Wl,--fatal-warnings
  post: |
    # copy the correct numpy config into the build artifacts. Otherwise scipy will try to build with the config
    # from the build computer and bad things will happen
    cp config/* $PKGDIR/../.artifacts/lib/python/numpy-1.21.4-py3.9-emscripten_wasm32.egg/numpy/core/include/numpy
    cp -r $PKGDIR/../.artifacts/lib/python/numpy-1.21.4-py3.9-emscripten_wasm32.egg/numpy $PKGDIR/../.artifacts/lib/python

test:
  imports:
    - numpy

package:
  name: numpy
  version: 1.21.4

source:
  url: https://files.pythonhosted.org/packages/fb/48/b0708ebd7718a8933f0d3937513ef8ef2f4f04529f1f66ca86d873043921/numpy-1.21.4.zip
  sha256: e6c76a87633aa3fa16614b61ccedfae45b91df2767cf097aa9c933932a7ed1e0

  patches:
    - patches/disable-maybe-uninitialized.patch
    - patches/dont-include-execinfo.patch
    - patches/fix-longdouble.patch
    - patches/fix-static-init-of-nditer-pywrap.patch
    - patches/init-alloc-cache.patch
    - patches/use-local-blas-lapack.patch
    - patches/make-int-return-values.patch
    - patches/fix-ieee754.patch
    - patches/disable-optimization.patch
    - patches/not-build-lapack-lite-as-64-bit.patch
    - patches/fix-invalid-asm-instruction.patch
    - patches/fix-comparator-function-signatures.patch
    - patches/fix-random_float_fill-return-type.patch

build:
  skip_host: False
  # set linker and C flags to error on anything to do with function declarations being wrong.
  # In webassembly, any conflicts mean that a randomly selected 50% of calls to the function
  # will fail. Better to fail at compile or link time.
  cflags: |
    -include math.h
    -I config
    -Werror=implicit-function-declaration
    -Werror=mismatched-parameter-types
    -Werror=mismatched-return-types
  ldflags: |
    -Wl,--fatal-warnings
  prereplay: |
    export SRC_DIR=$(pwd)
    cd ../.. # Need to move out of source directory to import numpy
    cp -r config $SRC_DIR
    python$PYMAJOR.$PYMINOR -c '\
        from numpy.core.setup_common import C_API_VERSION as API, C_ABI_VERSION as ABI;\
        print(f"#define NPY_API_VERSION 0x{API:08x}\n#define NPY_ABI_VERSION 0x{ABI:08x}")' \
    >> $SRC_DIR/config/_numpyconfig.h
  post: |
    # copy the correct numpy config into the build artifacts. Otherwise scipy will try to build with the config
    # from the build computer and bad things will happen
    export NUMPY_INSTALL_PATH=$HOSTINSTALLDIR/lib/python$PYMAJOR.$PYMINOR/site-packages/numpy/
    cp $SRC_DIR/config/* $NUMPY_INSTALL_PATH
    mkdir -p $NUMPY_LIB
    find $SRC_DIR -name '*.a' | sed "s:.*:cp \0 $NUMPY_LIB:g" | bash
test:
  imports:
    - numpy
