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: CLAPACK
  version: 3.2.1

source:
  sha256: 6dc4c382164beec8aaed8fd2acc36ad24232c406eda6db462bd4c41d5e455fac
  url: http://www.netlib.org/clapack/clapack.tgz
  extract_dir: CLAPACK-3.2.1
  patches:
    - patches/0001-add-missing-import.patch
    - patches/0002-fix-arith-h.patch
    - patches/0003-lapack-install-make.patch
    - patches/0004-fix-f2clibs-build.patch
    - patches/0005-remove-redundant-symbols.patch
    - patches/0006-correct-return-types.patch
  extras:
    - [make.inc, make.inc]

build:
  sharedlibrary: true
  script: |
    # The archive's contents have default permission 0750. If we use docker
    # to build, then we will not own the contents in the host, which means
    # we cannot navigate into the folder. Setting it to 0750 makes it
    # easier to debug.
    chmod -R o+rx .

    # In CLAPACK's Makefiles, some commands are mistakenly (?) hardcoded
    # instead of using the right variables
    sed -i 's/^	-ranlib /^	$(RANLIB)/' **/Makefile
    sed -i 's/^	ar /^	$(ARCH)/' **/Makefile
    sed -i 's/^	ld /^	$(LD)/' **/Makefile

    emmake make -j ${PYODIDE_JOBS:-3} blaslib lapacklib
    mkdir -p dist/lib
    emcc blas_WA.a lapack_WA.a F2CLIBS/libf2c.a -sSIDE_MODULE -o dist/lib/clapack_all.so

package:
  name: CLAPACK
  version: 3.2.1

source:
  sha256: 6dc4c382164beec8aaed8fd2acc36ad24232c406eda6db462bd4c41d5e455fac
  url: http://www.netlib.org/clapack/clapack.tgz
  extract_dir: CLAPACK-3.2.1
  patches:
    - patches/0001-add-missing-import.patch
    - patches/0002-fix-arith-h.patch
    - patches/0003-lapack-install-make.patch
    - patches/0004-fix-f2clibs-build.patch
    - patches/0005-remove-redundant-symbols.patch
    - patches/0006-correct-return-types.patch
  extras:
    - [make.inc, make.inc]

build:
  sharedlibrary: true
  script: |
    # The archive's contents have default permission 0750. If we use docker
    # to build, then we will not own the contents in the host, which means
    # we cannot navigate into the folder. Setting it to 0750 makes it
    # easier to debug.
    chmod -R o+rx .

    # In CLAPACK's Makefiles, some commands are mistakenly (?) hardcoded
    # instead of using the right variables
    sed -i 's/^	-ranlib /^	$(RANLIB)/' **/Makefile
    sed -i 's/^	ar /^	$(ARCH)/' **/Makefile
    sed -i 's/^	ld /^	$(LD)/' **/Makefile

    emmake make -j ${PYODIDE_JOBS:-3} blaslib lapacklib
    mkdir -p dist/lib
    emcc blas_WA.a lapack_WA.a F2CLIBS/libf2c.a -sSIDE_MODULE -o dist/lib/clapack_all.so
