Rooba
/
pyodide
mirror of https://github.com/pyodide/pyodide.git
1
1
Fork 0
Code Issues Packages Projects Releases Wiki Activity
pyodide/packages/numpy/meta.yaml

42 lines
1.5 KiB
YAML
Raw Normal View History

MVP of a proper packaging system
2018-06-20 18:54:47 +00:00
package:
name: numpy
Upgrade numpy to 1.21.4 (#1934)
2021-11-14 14:03:56 +00:00
version: 1.21.4
MVP of a proper packaging system
2018-06-20 18:54:47 +00:00
source:
Upgrade numpy to 1.21.4 (#1934)
2021-11-14 14:03:56 +00:00
url: https://files.pythonhosted.org/packages/fb/48/b0708ebd7718a8933f0d3937513ef8ef2f4f04529f1f66ca86d873043921/numpy-1.21.4.zip
sha256: e6c76a87633aa3fa16614b61ccedfae45b91df2767cf097aa9c933932a7ed1e0
MVP of a proper packaging system
2018-06-20 18:54:47 +00:00
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
Fix #115: Forcibly use the local copy of blas and lapack
2018-08-20 22:19:25 +00:00
- patches/use-local-blas-lapack.patch
Make f2c functions return int This patch makes everything in numpy, scipy and CLAPACK that began life as a fortran subroutine return int, whereas before they were a smattering of void plus lots of int, with a bunch of conflicts where the same function was defined as int in some and void in others. This matters because on upstream emscripten, these packages will not build due to linker conflicts, as the wasm linker can't link a function returning int to a function returning void. Annoyingly, this has to be int return not void, because whereas a normal fortran subroutine doesn't return anything, there's an obscure feature of fortran 77 called alternative returns which allows subroutines to say they want to return by jumping to some other place in the code. f2c handles this with integer return values.
2021-01-09 09:44:41 +00:00
- patches/make-int-return-values.patch
Update to numpy 1.17.5 (#887)
2021-03-23 21:49:38 +00:00
- patches/fix-ieee754.patch
Upgrade numpy to 1.21.4 (#1934)
2021-11-14 14:03:56 +00:00
- patches/disable-optimization.patch
- patches/not-build-lapack-lite-as-64-bit.patch
- patches/fix-invalid-asm-instruction.patch
Fix numpy comparator functions (#2110)
2022-01-16 23:52:34 +00:00
- patches/fix-comparator-function-signatures.patch
Fix numpy fatal error: incorrect random_float_fill return type (#2137) Upstream PR numpy/numpy#20911
2022-01-27 08:13:32 +00:00
- patches/fix-random_float_fill-return-type.patch
No replay (#2256) Our package build process currently has a significant flaw: we first run setup.py, recording all compilation commands, then we rewrite these compilation commands to invoke emcc and replay them, and then we pray that the cross compiled executables ended up in the right place to go into the wheel. This is not a good strategy because the build script is allowed to implement arbitrary logic, and if it moves, renames, etc any of the output files then we lose track of them. This has repeatedly caused difficulty for us. However, we also make no particularly significant use of the two pass approach. We can just do the simpler thing: capture the compiler commands as they occur, modify them as needed, and then run the fixed command. I also added a patch to fix the numpy feature detection for wasm so that we don't have to include _npyconfig.h and config.h, numpy can generate them in the way it would for a native build. I opened a numpy PR that would fix the detection for us upstream: numpy/numpy#21154 This clears the way for us to switch to using pypa/build (as @henryiii has suggested) by removing our dependence on specific setuptools behavior. This is on top of #2238.
2022-03-13 18:39:06 +00:00
- patches/fix-math-feature-detection-for-wasm.patch
MVP of a proper packaging system
2018-06-20 18:54:47 +00:00
build:
Update to Python 3.9.5 (#1637) Co-authored-by: Roman Yurchak <rth.yurchak@gmail.com>
2021-06-19 22:49:25 +00:00
cflags: |
No replay (#2256) Our package build process currently has a significant flaw: we first run setup.py, recording all compilation commands, then we rewrite these compilation commands to invoke emcc and replay them, and then we pray that the cross compiled executables ended up in the right place to go into the wheel. This is not a good strategy because the build script is allowed to implement arbitrary logic, and if it moves, renames, etc any of the output files then we lose track of them. This has repeatedly caused difficulty for us. However, we also make no particularly significant use of the two pass approach. We can just do the simpler thing: capture the compiler commands as they occur, modify them as needed, and then run the fixed command. I also added a patch to fix the numpy feature detection for wasm so that we don't have to include _npyconfig.h and config.h, numpy can generate them in the way it would for a native build. I opened a numpy PR that would fix the detection for us upstream: numpy/numpy#21154 This clears the way for us to switch to using pypa/build (as @henryiii has suggested) by removing our dependence on specific setuptools behavior. This is on top of #2238.
2022-03-13 18:39:06 +00:00
-Wno-return-type
Emscripten 2.0.12 Upstream backend (#1102) Co-authored-by: Dexter Chua <dalcde@users.noreply.github.com> Co-authored-by: Roman Yurchak <rth.yurchak@gmail.com>
2021-02-06 07:58:12 +00:00
post: |
Use pypa/build (#2272) This resolves #2189. > build isolation would be a bit difficult to use in our case, as for instance > when building scipy we need the patched numpy on the host and not the numpy > version specified in pyproject.toml (which would be unpatched) This is indeed the case, certain packages cannot be isolated. My strategy is to make a list of packages that shouldn't be isolated and add symlinks from the isolated build environment into the `.artifacts` directory to "unisolate" them. Then we remove the unisolated package requirements from the list of packages to install, in case pesky constraints aren't satisfied. In particular, packages that expect to be used with `pypa/build` often feel free to put very specific constraints on their build dependencies (often asking them to be == to a particular version). Specific version constraints is good for build reproducibility and with build isolation doesn't cost anything. So we just ignore the constraints. Hopefully nothing goes wrong. In particular, any package that does stuff both at build time and at runtime and requires synchronization between the build time and run time environments needs the unisolation. This includes cffi with `_cffi_backend.so`, and of course numpy and scipy. pycparser needs to be unisolated because it is a dependency of cffi. Currently I have also unisolated pythran and cython, though these are build time only tools and do not really need to be unisolated. Cython I unisolated specifically because numcodecs needs it but it isn't in the numcodecs build dependencies. Pythran I unisolated because of a problem with the scipy build which I don't fully understand (some problem with long double feature detection).
2022-03-22 05:05:30 +00:00
pip install -t $HOSTSITEPACKAGES numpy==$PKG_VERSION
Emscripten 2.0.12 Upstream backend (#1102) Co-authored-by: Dexter Chua <dalcde@users.noreply.github.com> Co-authored-by: Roman Yurchak <rth.yurchak@gmail.com>
2021-02-06 07:58:12 +00:00
# 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
Use pypa/build (#2272) This resolves #2189. > build isolation would be a bit difficult to use in our case, as for instance > when building scipy we need the patched numpy on the host and not the numpy > version specified in pyproject.toml (which would be unpatched) This is indeed the case, certain packages cannot be isolated. My strategy is to make a list of packages that shouldn't be isolated and add symlinks from the isolated build environment into the `.artifacts` directory to "unisolate" them. Then we remove the unisolated package requirements from the list of packages to install, in case pesky constraints aren't satisfied. In particular, packages that expect to be used with `pypa/build` often feel free to put very specific constraints on their build dependencies (often asking them to be == to a particular version). Specific version constraints is good for build reproducibility and with build isolation doesn't cost anything. So we just ignore the constraints. Hopefully nothing goes wrong. In particular, any package that does stuff both at build time and at runtime and requires synchronization between the build time and run time environments needs the unisolation. This includes cffi with `_cffi_backend.so`, and of course numpy and scipy. pycparser needs to be unisolated because it is a dependency of cffi. Currently I have also unisolated pythran and cython, though these are build time only tools and do not really need to be unisolated. Cython I unisolated specifically because numcodecs needs it but it isn't in the numcodecs build dependencies. Pythran I unisolated because of a problem with the scipy build which I don't fully understand (some problem with long double feature detection).
2022-03-22 05:05:30 +00:00
export NUMPY_CORE_INCLUDE=numpy/core/include/numpy
cp \
build/numpy-$PKG_VERSION/build/src.emscripten_wasm32-$PYMAJOR.$PYMINOR/$NUMPY_CORE_INCLUDE/*config.h \
$HOSTSITEPACKAGES/$NUMPY_CORE_INCLUDE
No replay (#2256) Our package build process currently has a significant flaw: we first run setup.py, recording all compilation commands, then we rewrite these compilation commands to invoke emcc and replay them, and then we pray that the cross compiled executables ended up in the right place to go into the wheel. This is not a good strategy because the build script is allowed to implement arbitrary logic, and if it moves, renames, etc any of the output files then we lose track of them. This has repeatedly caused difficulty for us. However, we also make no particularly significant use of the two pass approach. We can just do the simpler thing: capture the compiler commands as they occur, modify them as needed, and then run the fixed command. I also added a patch to fix the numpy feature detection for wasm so that we don't have to include _npyconfig.h and config.h, numpy can generate them in the way it would for a native build. I opened a numpy PR that would fix the detection for us upstream: numpy/numpy#21154 This clears the way for us to switch to using pypa/build (as @henryiii has suggested) by removing our dependence on specific setuptools behavior. This is on top of #2238.
2022-03-13 18:39:06 +00:00
# static libraries for other packages to link
Better package cross compilation (#2238) Co-authored-by: Gyeongjae Choi <def6488@gmail.com>
2022-03-10 04:34:25 +00:00
mkdir -p $NUMPY_LIB
find $SRC_DIR -name '*.a' | sed "s:.*:cp \0 $NUMPY_LIB:g" | bash
Address review comments
2018-08-03 12:43:40 +00:00
test:
imports:
- numpy