Author jlvandenhout
Recipients dstufft, eric.araujo, jdemeyer, jlvandenhout
Date 2019-06-13.10:33:38
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1560422018.69.0.718114959504.issue37247@roundup.psfhosted.org>
In-reply-to
Content
> 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.
History
Date User Action Args
2019-06-13 10:33:38jlvandenhoutsetrecipients: + jlvandenhout, eric.araujo, jdemeyer, dstufft
2019-06-13 10:33:38jlvandenhoutsetmessageid: <1560422018.69.0.718114959504.issue37247@roundup.psfhosted.org>
2019-06-13 10:33:38jlvandenhoutlinkissue37247 messages
2019-06-13 10:33:38jlvandenhoutcreate