Switch to CPython way to build standard C extensions. #1354
Conversation
| @@ -158,21 +156,7 @@ add_library(FROM_CPYTHON OBJECT ${STDMODULE_SRCS} ${STDOBJECT_SRCS} ${STDPYTHON_ | |||
| add_dependencies(FROM_CPYTHON copy_stdlib) | |||
|
|
|||
| set(STDMODULES | |||
| ${CMAKE_BINARY_DIR}/lib/python2.7/lib-dynload/bz2.pyston.so | |||
There was a problem hiding this comment.
Just curious, why do you want to remove these lines? It's definitely annoying that we have to duplicate all this between the setup.py and CMakeLists.txt (and same with the source files), but it means that our cmake system will end up knowing what the setup.py will do. I think concretely the features it gets us are 1) not having to run setup.py if none of the dependencies change, and 2) properly packaging the .so's into a release tarball.
How would you feel about keeping these definitions + potentially adding any new ones from the new setup.py? We could probably handle the .c files by using a glob_recurse, but we might have to list out all the .so files we are expecting.
There was a problem hiding this comment.
ok, I am fine with keep these definitions. And what about comment out bunch of codes inside setup.py. My idea is enable those commented code when necessary. For example, this PR comment out the tk related code. And we can enable it in my tk_support PR. But not enable it for now. What do you think?
There was a problem hiding this comment.
First of all, this is minor, but let's try to always copy from v2.7.7 of CPython. There aren't that many changes between the micro versions so it's not that huge of a deal, but it helps us if we have a convention around it (for example if we try to find any remaining Pyston changes).
I think changing setup.py is perfectly fine if we don't support all of it yet. My only recommendation would be to try to minimize the size of the diff so that it's more understandable (1500 changed lines is quite a lot). For example, if we are commenting out the calls to certain functions, we probably don't need to comment out the functions themselves. And if we don't support some feature such as multi-platform, instead of commenting out all of that code we could maybe just hard-code the platform.
Daetalus
force-pushed
the
building_issue
branch
6 times, most recently
from
1f8e262 to
b426914
Compare
|
Hi, @kmod, after some simplification, the second patch's diff deduced |
Daetalus
force-pushed
the
building_issue
branch
from
b426914 to
e132792
Compare
Disable some extensions, part of because they were handled by from_cpython/CMakefile.txt, part of beacuase we need to enable it in seperated PR. Such as tk extension. And also add some modifications to let extension can find the source code in correct path.
|
Awesome, really nice improvement :) |
Copy CPython setup.py and add lots of Pyston changes.