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 lemburg
Recipients Arfrever, barry, brett.cannon, eric.snow, lemburg, ncoghlan, ned.deily, pitrou, steve.dower, tim.golden, vstinner, zach.ware
Date 2014-12-02.18:59:34
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <547E0C11.7040200@egenix.com>
In-reply-to <1417545972.07.0.657727614385.issue22980@psf.upfronthosting.co.za>
Content
On 02.12.2014 19:46, Antoine Pitrou wrote:
> 
>> Note that on Linux, 32-bit and 64-bit versions are typically placed
>> into different directory trees
> 
> By whom? Our standard installer doesn't (it uses ../lib/python-X.Y for all builds).

By the system vendors. Packages (with extensions) will automatically
pick up their configuration.

> Also, one of the problems (and actually the problem which triggered this tracker entry) is when doing development inside a working copy (either through "setup.py develop" or "setup.py build_ext --inplace" - both copy C extensions directly into the source tree).

Fair enough; it's a rare use case, but may be worth supporting.

My main point was that we shouldn't start adding tags for e.g.
PPC, Intel, ARM, etc. since platforms needing to support multiple
such architectures will typically support fat builds anyway.

How about using these flags:

b0 - 16-bit
b1 - 32-bit
b2 - 64-bit
b3 - 128-bit
and so on
History
Date User Action Args
2014-12-02 18:59:34lemburgsetrecipients: + lemburg, barry, brett.cannon, ncoghlan, pitrou, vstinner, tim.golden, ned.deily, Arfrever, eric.snow, zach.ware, steve.dower
2014-12-02 18:59:34lemburglinkissue22980 messages
2014-12-02 18:59:34lemburgcreate