Jeroen van den Hout <jlvandenh...@gmail.com> added the comment:
> Adding a separate build step for SWIG (then the order would be build_swig, > build_py, build_ext) would be safer and IMHO also more logical. I like this suggestion and contemplated it. However SWIG interface files are defined in Extension instances, which are inherently tight to the build_ext command. Breaking this link would require introspection of extensions before deciding on which command to invoke, or a completely separate SWIG Extension class, both of which require a change in usage. > It's not uncommon for projects to extend distutils in various ways and the > proposed change may break those packages. I argue that those packages are already tempering with default behavior of distutils, while the change I am proposing is fixing a flaw in basic functionality and might I say 'implied behavior' of distutils (as the docs say distutils understands SWIG, while it isn't currently even capable of installing correctly when SWIG files are used). The build_ext and build_py commands are truly separate commands, except when SWIG interface files are used: - build_py is responsible for copying pure python files to their correct directories, potentially compiling them to .pyc files. - build_ext is responsible for compiling and linking C/C++ files and copying resultant files to their correct directories. It is only when SWIG files are supplied that a .py file is produced, which quite neatly would be picked up by build_py, given the chance. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue37247> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
