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.

classification
Title: Interix support
Type: compile error Stage:
Components: Build Versions: Python 2.7
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: benjamin.peterson, georg.brandl, jcea, loewis, mark.dickinson, mduft, r.david.murray, terry.reedy
Priority: normal Keywords: patch

Created on 2011-04-27 13:43 by mduft, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
python-2.7.1-interix.patch mduft, 2011-04-27 13:43 patch for python to build on intierix (with suacomp)
Messages (9)
msg134564 - (view) Author: Markus Duft (mduft) Date: 2011-04-27 13:43
Hey!

For a while now, i'm maintaining python build patches for interix for the gentoo prefix project. I thought maybe i can bring them upstream :) currently i have python 2.7.1 building, and i'll start testing python 3.2 in a while...

may i ask your opinions on my patch, and maybe inclusion in the repository...?

Regards, Markus
msg134598 - (view) Author: Jesús Cea Avión (jcea) * (Python committer) Date: 2011-04-27 17:12
I don't agree with some details of the patch (I would move the log-like calculation to a inline function, and document WHY it is needed at all, for instance), but supporting a new platform is good, moreover when the patch is so small.

I would ask for a seasoned Python-developer to decide the target for this. Personally I would be OK to target 2.7.2, 3.2.1 and 3.3. But since this would be considered a new feature the target would be 3.3. Given the special status of 2.7 (to be maintained for a long time), I would target it too. In any case, this is something that the release managers of each version should consider.

I am "nosy-ing" Benjamin Peterson (2.7) and Georg Brandl (3.2) as release managers. I am interested in their opinion. I don't think we should involucrate 3.1 with this, with 3.2 already published.

After that, we can discuss the patch details.

PS: Markus, could you possibly summarize intierix?. We would need a patch for 3.3 too. Maybe too for 3.2, if Georg opinion is favourable.
msg134601 - (view) Author: Jesús Cea Avión (jcea) * (Python committer) Date: 2011-04-27 17:30
Markus, could you possibly provide a buildbot running under Interix?. A virtual machine could be OK, if available 24x7, with reasonable resources (CPU, memory).
msg134649 - (view) Author: Markus Duft (mduft) Date: 2011-04-28 06:06
if the buildbot does not need to be reached from the outside, i could provide one, yes (i'm behind a company firewall/proxy infrastructure)

as for the patch: comments and improvement suggestions welcome :)

as for interix (actually SUA - Subsystem for UNIX Applications): It is a POSIX compatible layer on top of MS Windows (since 2000, up to currently 2008R2/7). I'm working on building gentoo prefix there, which brings a lot improvement to the rather outdated userland of interix (new GCC, python ;), new perl, etc.). Interix suffers from a few smaller problems, making it feel unstable in certain situations. For example, fork() tends to fail with EAGAIN, poll() does not work correctly, etc. To compensate this, i have build a library (suacomp.sf.net) which wraps a lot of library functions. my python fixes python just enough to work with suacomp installed. without suacomp, python will still build (as suacomp only wraps existing apis), but will not work too well (depending on what your doing).
msg134650 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2011-04-28 06:19
Guido established a policy a few years ago that we should rather not incorporate support for every minority platform for which people contribute patches. While I'd personally agree that an Interix port would certainly be "fun", pragmatically, I'm -1 on having the code in the code basis, and propose to close this issue as "won't fix".

We would certainly be happy to link to gentoo prefix from the "other ports" page on python.org.
msg134652 - (view) Author: Markus Duft (mduft) Date: 2011-04-28 06:23
since the patch is rather small, and prove to not "fluctuate" too much on releases, i'd be willing to keep maintaining them, although i think that it would not cause too much problems to integrate it into the code base.
msg134819 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2011-04-29 22:57
Markus, I agree with Martin that this patch would go against current policy and should be closed. Rather than close it myself, I will try to persuade you to do so.

First, CPython is actually in the process of 'slimming down', of removing, not adding support for minority platforms. Please look at
ttp://python.org/dev/peps/pep-0011/
and notice that support for 5 types of systems has been removed for 3.3 and 2 more are slated for removal in 3.4.

Second, buildbots are intended to be remote slaves of the master. When they finish one build, test, and report, there is (or soon will be) usually another version ready to test. I am pretty sure that does not work behind a corparate firewall. In any case, if you want to use a machine for anything else, you are better with a script that pulls, builds, and tests when *you* decide. Also, buildbots are usually dedicated to one version. You might want to test your patch with multiple versions.

Third, if you keep the code, then no one else can mess with it, even accidentally. You also get to decide exactly which Python versions you wish to support or not support.

Fourth, I think the few advantages of integration can be obtained by other means that are not much more difficult. This includes a link on the 'Other ports' page for the appropriate versions.
msg147384 - (view) Author: Jesús Cea Avión (jcea) * (Python committer) Date: 2011-11-09 23:45
Closing. If anybody disagrees, reopen.
msg147403 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2011-11-10 13:18
Just a note that buildbot does work behind a firewall (mine are set up that way). The client calls out to the master.  A really restrictive corporate firewall may need outbound holes punched, but there are no inbound connections to the client.
History
Date User Action Args
2022-04-11 14:57:16adminsetgithub: 56146
2011-11-10 13:18:17r.david.murraysetnosy: + r.david.murray
messages: + msg147403
2011-11-10 13:10:43mark.dickinsonsetnosy: + mark.dickinson
2011-11-09 23:45:04jceasetstatus: open -> closed
resolution: wont fix
messages: + msg147384
2011-04-29 22:57:18terry.reedysetnosy: + terry.reedy
messages: + msg134819
2011-04-28 06:23:07mduftsetmessages: + msg134652
2011-04-28 06:19:50loewissetmessages: + msg134650
2011-04-28 06:06:48mduftsetmessages: + msg134649
2011-04-27 17:34:17pitrousetnosy: + loewis
2011-04-27 17:30:16jceasetmessages: + msg134601
2011-04-27 17:12:05jceasetnosy: + georg.brandl, jcea, benjamin.peterson
messages: + msg134598
2011-04-27 13:43:44mduftcreate