-
Notifications
You must be signed in to change notification settings - Fork 69
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
[FR] Switch Windows builds to use LLVM (opensource Apache 2.0) instead of Visual Studio modules - clang-cl.exe and lld-link.exe #154
Comments
|
Hi.
|
Clang-cl has test suites with NumPy and SciPy and those at least pass all tests. I can't say for sure that EVERY library will work 100%, just that having the option to select a different linker and compiler would be helpful for some users. Every extension module I've built using clang-cl and lld-link works without issue alongside OpenMP and MSVC compiled Python (PYD files). I believe Python itself has no issue as the library is opensource, so the Build Tools are allowed. When using the Build Tools for commercial applications which are distributed, they fall under the Visual Studio license, which means if you distribute them, then you need to buy Visual Studio. So for the small subset of Python users that create compiled libraries and deploy them for commercial use, or use the compiled modules within a company >5 users, having an option to use LLVM tools instead at least gets past these restrictions. I already know how to "hack" the _msvccompiler.py to use LLVM tools, but some people don't. If it's easy to add that option then why not. Probably just switching every build over to these tools wouldn't make much sense, but adding an option to select them instead would. |
This project isn't wed to any particular compiler and is open to support additional compilers. Ideally, it should also present one preferred compiler for each platform such that users get a consistent, predictable experience, and for Windows, that's likely to be the MS compiler. If presenting alternate compilers, there should be a straightforward way to opt into that compiler on an individual or environment basis. It should also include tests, which may prove somewhat difficult to integrate (see cygwin jobs in the CI runs on pypa/distutils for an example). It might even be desirable to refactor the code to allow for modular compilers. Since most of the compiler logic is currently maintained in distutils, probably the implementation will need to happen in pypa/distutils. Please feel free to work on a solution, though be aware that this feature request is rather a big one and not something that will be solved in a simple patch. I'm happy to help guide as you work through concepts and an implementation. |
See #7 for a previous PR. Note that using clang-cl.exe does not mean that the extension module will not link to MSVC libraries. Clang-cl generated executables and the extension modules still link to MSVC libraries |
What's the problem this feature will solve?
The current builds of Python for Windows use the MSVC 14.X libraries which are covered under the Microsoft Visual Studio licenses. This means that any extension modules that are generated also fall under the same Microsoft licenses. Which is contrary to the the whole point of Python in general - the whole library should be OPEN SOURCE. So the very easy thing to do on Windows is to switch to the LLVM compilers that are 100% compatible with the MSVC builds. Since they already exist under LLVM (clang-cl.exe and lld-link.exe) the project SHOULD move toward their adoption, rather than continuing to use closed source build tools.
Describe the solution you'd like
Simply switch the default build tools for Python modules to use the LLVM
clang-cl.exe
andlld-link.exe
so that Python on Windows is actually open-source, i.e. Apache 2.0 license.Alternative Solutions
Well if you use MSVC to build Python it's always going to fall under the commercial license when people try to extend the functionality via compiled modules.
Additional context
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: