On 01 December 2000, Thomas Heller said:
Distutils currently only supports build_*** commands for C-libraries and Python extensions.
Shouldn't there also be build commands for shared libraries, executable programs and static Python binaries?
Andrew and I talked about this a bit yesterday, and the proposed interface is as follows: python setup.py build_ext --static will compile all extensions in the current module distribution, but instead of creating a .so (.pyd) file for each one, will create a new python binary in build/bin.<plat>. Issue to be resolved: what to call the new python binary, especially when installing it (presumably we *don't* want to clobber the stock binary, but supplement it with (eg.) "foopython"). Note that there is no provision for selectively building some extensions as shared. This means that Andrew's Distutil-ization of the standard library will have to override the build_ext command and have some extra way to select extensions for shared/static. Neither of us considered this a problem.
BTW: Distutils-sig seems pretty dead these days...
Yeah, that's a combination of me playing on other things and python.net email being dead for over a week. I'll cc the sig on this and see if this interface proposal gets anyone's attention. Greg
(damn, the original reply was killed by a crash of outlook express. Have to type it all again).
On 01 December 2000, Thomas Heller said:
Distutils currently only supports build_*** commands for C-libraries and Python extensions.
Shouldn't there also be build commands for shared libraries, executable programs and static Python binaries?
Andrew and I talked about this a bit yesterday, and the proposed interface is as follows:
python setup.py build_ext --static
will compile all extensions in the current module distribution, but instead of creating a .so (.pyd) file for each one, will create a new python binary in build/bin.<plat>.
What do you mean by 'static'? On windows, there are three possibilities for extensions to live in: 1. pythonxx.dll (the usual python interpreter) 2. separate shared extension module 'zlib.pyd' 3. python.exe (which loads pythonxx.dll, and call Py_Main) 4. SpecialPython.exe (which has the python interpreter built in as well as other extension modules. *ALL* extension modules have to be builtin on windows, because backlinking into executables does not work!) 1) is what Andrew cares about (on windows), 2) is already handled by distutils, 3) and 4) is what I am interested in!
Issue to be resolved: what to call the new python binary, especially when installing it (presumably we *don't* want to clobber the stock binary, but supplement it with (eg.) "foopython").
Note that there is no provision for selectively building some extensions as shared. This means that Andrew's Distutil-ization of the standard library will have to override the build_ext command and have some extra way to select extensions for shared/static. Neither of us considered this a problem.
BTW: Distutils-sig seems pretty dead these days...
Yeah, that's a combination of me playing on other things and python.net email being dead for over a week. I'll cc the sig on this and see if this interface proposal gets anyone's attention.
Thomas
participants (2)
-
Greg Ward -
Thomas Heller