add python bindings #33
Conversation
This allows for constructing MLIR using Python classes rather than C++ classes. Programs can be written, compiled, and executed all from within Python.
…nda-forge-pinning 2022.12.20.19.40.49
I don't like this solution, but it is better to get something working and kick this problem down the road. Mac M1 machines can always build an x86-64 environment, so this is more of an inconvenience than a show-stopper for any user.
This allows for constructing MLIR using Python classes rather than C++ classes. Programs can be written, compiled, and executed all from within Python.
…nda-forge-pinning 2022.12.20.19.40.49
I don't like this solution, but it is better to get something working and kick this problem down the road. Mac M1 machines can always build an x86-64 environment, so this is more of an inconvenience than a show-stopper for any user.
Only include the cmake options for Python when building mlir-python-bindings
|
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
|
cc @jim22k |
|
@isuruf Thanks for picking this back up! I wasn't sure if it could work with only one output depending on python+numpy. I started to add a separate mlir-python-bindings feedstock pinned to the specific MLIR version, but if we can get this working within this feedstock, it will be less of a maintenance burden for new releases of MLIR. |
| # Can't have llvmdev in BUILD_PREFIX as llvmdev conflicts with the clang compiler | ||
| # TODO: remove conflict between llvmdev and clang compiler | ||
| conda create -p $BUILD_PREFIX/llvm llvmdev=$PKG_VERSION -c conda-forge --yes --quiet |
There was a problem hiding this comment.
This seems like a superset of conda-forge/clangdev-feedstock#196, where we can't mix our OSX compilers with newer libclang, or in this case: llvm.
Would this be solvable by using clang_bootstrap here? Otherwise I can't see how we can build clang against a shared libllvm (though currently we don't distinguish that precisely, we just have llvmdev == {{ version }} in host/run everywhere; so perhaps this can be broken down to be more finer-grained, or we build clang against a static llvm)
|
Is this only an issue with OSX Arm? If so, I would be fine with excluding that case. Users who need the mlir-python-bindings on M1 Mac can still create an x86 conda environment. |
|
@isuruf My attempt at creating a separate |
|
Closing this as solved by conda-forge/staged-recipes#21954 |
Checklist
0(if the version changed)conda-smithy(Use the phrase@conda-forge-admin, please rerenderin a comment in this PR for automated rerendering)