This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author shreyanavigyan
Recipients WildCard65, docs@python, paul.moore, shreyanavigyan, steve.dower, tim.golden, zach.ware
Date 2021-05-10.15:53:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1620662007.17.0.495683678111.issue43804@roundup.psfhosted.org>
In-reply-to
Content
Zachary:
> As I said on the first PR, and as William says above, I don't see any indication that your assertion that some commands are 32-bit only is true.  Please provide some evidence for your claim.

cl.exe by default points to the 32-bit cl.exe not the 64-bit cl.exe. And also the library used by cl.exe by default is also 32-bit. Therefore there seems to be a linker issue. And I've tested that. It's true.

Steve:
> Most likely we should preface that section with a "we recommend using a third-party build backend for your package, such as ... and refer to packaging.python.org for up to date suggestions" and then the rest of the section shows literally the build steps to compile an extension module (so that build backend authors have a reference).
We should *not* have a section on using setuptools, or if we do, it should consist entirely of a link to the latest setuptools documentation. Their interface is not tied to our release schedule, and could change at any time, invalidating our docs (which is a *good* thing, provided we haven't documented them).

I'll remove the changes in Building C and C++ Extensions. I'll also make sure no changes are referencing setuptools. I'll be opening PR very soon.
History
Date User Action Args
2021-05-10 15:53:27shreyanavigyansetrecipients: + shreyanavigyan, paul.moore, tim.golden, docs@python, zach.ware, steve.dower, WildCard65
2021-05-10 15:53:27shreyanavigyansetmessageid: <1620662007.17.0.495683678111.issue43804@roundup.psfhosted.org>
2021-05-10 15:53:27shreyanavigyanlinkissue43804 messages
2021-05-10 15:53:27shreyanavigyancreate