-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
barvinok? #15
Comments
Use this script (or some variant) to build: https://github.com/inducer/islpy/blob/master/build-with-barvinok.sh Doing so will (currently) give you |
Thanks. I just tried the above script and got a bunch of linker problems.
any ideas? |
Python headers not matching your Python executable? |
I figured out the reason --- I think the current cffi build script is dynamically runtime resolving these symbols in g++ with the "-shared" flag. Thus it is not needing libpython during linking stage. However, I'm using clang++, and "-shared" is not enough for dynamic resolution of these symbols. I need to do
|
Happy to hear you figured it out, and thanks for sharing what you learned. |
Hello, I would also really like to use checking for llvm-config... yes Any help or suggestions would be great! Thanks! |
@lbang-hmc Try installing the development files for clang. |
Just got back from vacation and tried this out. After a little fiddling with what I had already done and then using the updated scripts, it works! Many thanks! |
I know that this is an old issue. Is there any chance islpy can integrate barvinok into the pypi package? Potentially with something like: pip install islpy[barvinok] would be very neat! What would be the main bottleneck till something like above can be supported? Is it the shipping of barvinok? Ref. "extra_requires" in https://setuptools.readthedocs.io/en/latest/references/keywords.html |
The main issue is that barvinok has fairly complex build dependencies, see the script. I don't think we can usefully package that complex of a C/C++ build operation into setuptools. It might be possible to ship a binary wheel (and I'd be happy to consider a PR for a CI job that does builds one). |
FWIW: See the existing wheel-building job that @isuruf worked on recently. Note that I'm not sure I'd like the default wheels to have barvinok support, because it is GPL. |
For a binary wheel using something like |
@isuruf I don't see why that is necessary though? I'm imagining the current setup where we just have the |
As @inducer said, |
How about we just let setup.py invoke |
I'm not sure what you mean. The main point of wheels is that they're binaries that are distributable through the package index. |
Wouldn't it be possible to only let the wheel which has barvinok baked-in to use a GPL license? |
Yes. The licensing isn't the complicated part. It'll just never happen for the upstream islpy wheels, because those must remain under the MIT license that they are currently under. If you'd like to ship separate islpy wheels (either through a separate pypi project, or as build variants if the package index supports such a thing) and you're volunteering to do the release engineering involved (and/or contribute that to islpy), you're more than welcome. |
An alternative is to call |
I see that there's some work on barvinok support. How do I enable it?
If it's still under construction, I can also help on that.
The text was updated successfully, but these errors were encountered: