Switch to scikit-build
Scikit-build is an improved build system generator that automatically prefers the ninja build system.
@xoviat, thanks for doing this. I wanted to check and fix scikit-build regarding https://github.com/symengine/symengine.py/pull/144#issuecomment-304048013 but I haven't had time to look at it. Do you know if they have been resolved?
@isuruf Would you mind filing issues on the scikit-build repository? If the issue is not filed, it is no surprise that nothing is done.
Will do tonight
@xoviat thanks for working on this. I am all for offloading the heavy lifting to scikit-build.
How important is cross-compile MinGW support?
While the binaries provided in releases are python 3.5+ only, we do build and test with MinGW and MSVC 2015 for python 2.7 support. By 2020, we'll drop 2.7 support, but until then, I'd like to keep 2.7 support if that's not too much trouble.
To be clear, I'm not discussing dropping Python 2.7 support. I'm discussing dropping support for MinGW and Python 3.5+ on windows.
I'm discussing dropping support for MinGW and Python 3.5+ on windows.
That's okay
I don't know what the cause of the import failure that occurs on Travis-CI is. The files seem to be installed to their correct locations.
Shot in the dark (not sure at all it applies here): at least with pytest (don't use nosetests much myself) I've had strange problems unless I specified zip_safe=False.
cc @isuruf
cc @isuruf
@isuruf I still think this is a good idea in general to switch to scikit-build, as it should simplify the build system that we have to maintain. What do you think?
Yes, I'm in favor of using scikit-build too. This PR has to be improved before merging though. Removing the --symengine-dir option to specify symengine C++ build directory limits my development workflow.