With the trend to use REST APIs between the cloud and the IoT there is increasing interest in Python on embedded devices.  Cloud developer’s typical release a reference REST implementation of JSON and/or Python on Linux and leave it to the device developer to adapt it to their platform.   While many devices use eLinux, others with IP and/or hard real-time constraints need a commercial RTOS platform. 

Currently the automake configure explicitly prevents configuration of VxWorks as a build target.

I'll provide a pull request referencing this issue with the required changes.

The following might be relevant to this issue:
https://www.python.org/dev/peps/pep-0011/#supporting-platforms

To support a new platform, you need a developer who can support this platform next years, a working buildbot, etc. You can start a discussion on python-dev to get a first feedback.

Without a strong support, this issue should be fixed a REJECTED and a patch should be maintainted out of the tree. Since the PR seems small, it should be "easy" to keep a fork of CPython up to date.

FYI I already started a thread on python-dev:
[Python-Dev] Partial support of a platform
https://mail.python.org/pipermail/python-dev/2017-November/150238.html

I'm quite happy to take on maintainer role for Python on VxWorks, so I think we can get that one solved. 

Enabling a build bot for cross compile of propitiatory OS presents a number of legal licensing issues that outside my control. And I'll discuss it internally at Wind River. However I think it is in line with where our customers want us to go, so well worth pursuing. 

I'll keep this pull request active and up to date, till the broader issues you have raised can be resolved.      

I'll post a proposal on the mailing list after I consulted within Wind River.

Many thanks for your interest and support.

I'm not sure what licensing issues you are talking about, but setting up a buildbot shouldn't normally run into any.  As long as you have a license to the run the OS, the fact that you are using it to receive jobs from our build master and run them shouldn't be a problem.  You can keep the whole thing behind a firewall in a DMZ: the slave makes outbound connections to pick up its jobs.

On the other hand, the logistics of setting up a cross compile buildbot might be a bit complex, I've never done that.  You might need specific support from our build master.  In any case, the python-buldbots mailing list is the place to talk if you want to/can pursue this.

As I commented on the PR, I think this PR should not be merged until and if there is a consensus that this support belongs in the standard cpython repo and there is an agreed-upon plan how this platform would be supported on going.  I think it needs an approved PEP.  We've allowed ourselves in the past to do a long-term disservice to our downstream users by merging in support for platforms that we were not equipped to support.  In any case, it would need to wait for 3.8.

Kuhl, Brian started a new discussion: [Python-Dev] VxWorks and cpython?
https://mail.python.org/pipermail/python-dev/2019-January/156024.html

PR 11968 and PR 12051 are small and reasonable.

IMHO we can take decisions on a case by case basic. But WindRiver plans to provide a buildbot and is already showing their will to propose PRs, so it seems like things are moving on.

New changeset 32f5fdd7f4213743fe2f6eedd0fe2108f3157021 by Victor Stinner (pxinwr) in branch 'master':
bpo-31904: Add cross-build support for VxWorks RTOS (GH-11968)
https://github.com/python/cpython/commit/32f5fdd7f4213743fe2f6eedd0fe2108f3157021

New changeset f4b0a1c0da80318e0a4f4c70d2722f01ce3512dd by Victor Stinner (pxinwr) in branch 'master':
bpo-31904: Add encoding support for VxWorks RTOS (GH-12051)
https://github.com/python/cpython/commit/f4b0a1c0da80318e0a4f4c70d2722f01ce3512dd

New changeset 8b5bdda5b4c418c4a858f183763d0a497170977c by Victor Stinner (pxinwr) in branch 'master':
bpo-31904: Adapt the _signal module to VxWorks RTOS (GH-12304)
https://github.com/python/cpython/commit/8b5bdda5b4c418c4a858f183763d0a497170977c

Please stop to send new PRs which depend on other PRs which are not merged yet, it becomes too hard to follow :-( Let's focus on first PRs.

New changeset f4333d0479d6974d142e858522e95cbf8381f016 by Victor Stinner (hliu0) in branch 'master':
bpo-31904: Fix test_utf8_mode on VxWorks (GH-12428)
https://github.com/python/cpython/commit/f4333d0479d6974d142e858522e95cbf8381f016

I'm against implementing crypt on top of OpenSSL's DES_crypt. Please don't support the module at all instead of just supporting a completely broken implementation.

Please stop adding more pull requests, I cannot review too many at the same time. I would prefer to have a limit of 4 open PRs. I don't propose to close existing ones. Just stop to add more :-)

New changeset 236d0b75c41449a266201c683b4b0d6acdee02df by Victor Stinner (pxinwr) in branch 'master':
bpo-31904: Don't build the _crypt extension on VxWorks (GH-12833)
https://github.com/python/cpython/commit/236d0b75c41449a266201c683b4b0d6acdee02df

New changeset f1464f4d2ecf9b809ff768c523c5eea1abd31c55 by Victor Stinner (pxinwr) in branch 'master':
bpo-31904: Port the time module on VxWorks (GH-12305)
https://github.com/python/cpython/commit/f1464f4d2ecf9b809ff768c523c5eea1abd31c55

@vstinner I've informed WRS team of temporarily not creating new PRs in until less than 4 PRs are in the open state. Next we will keep open PRs less than 4. Thanks for your effort on them.

New changeset 36c41bc2017921321dbb19557f616a6bb7572c83 by Victor Stinner (Lihua Zhao) in branch 'master':
bpo-31904: Fix test_tabnanny on VxWorks (GH-12646)
https://github.com/python/cpython/commit/36c41bc2017921321dbb19557f616a6bb7572c83

New changeset 2954550818e5c23a082e6279eb326168230ebf04 by Victor Stinner (Lihua Zhao) in branch 'master':
bpo-31904:  Port test_cmd_line to VxWorks (#12648)
https://github.com/python/cpython/commit/2954550818e5c23a082e6279eb326168230ebf04

New changeset 693c104ae74feea11f0b51176dc91ecd153230c0 by Victor Stinner (Lihua Zhao) in branch 'master':
bpo-31904: Port test_resource to VxWorks (GH-12719)
https://github.com/python/cpython/commit/693c104ae74feea11f0b51176dc91ecd153230c0

New changeset f2d7ac7e5bd821e29e0fcb78a760a282059ae000 by Victor Stinner (pxinwr) in branch 'master':
bpo-31904: Add posix module support for VxWorks (GH-12118)
https://github.com/python/cpython/commit/f2d7ac7e5bd821e29e0fcb78a760a282059ae000

Please update PR 12670: see my comment there.

New changeset 5cd28030092eaa8eb9223afd733974fd2afc8e2c by pxinwr in branch 'master':
bpo-31904: Fix test_c_locale_coercion encodings for VxWorks RTOS (GH-19448)
https://github.com/python/cpython/commit/5cd28030092eaa8eb9223afd733974fd2afc8e2c

New changeset 855e68855eeb06f8f0319b3366d3a012c2ff2041 by pxinwr in branch 'master':
bpo-31904: Fix test_ftplib failures for VxWorks RTOS (GH-19447)
https://github.com/python/cpython/commit/855e68855eeb06f8f0319b3366d3a012c2ff2041

Is it safe to say that there is an now intent to support VxWorks within the main tree, with Wind River agreeing to be primary support?

And this ticket has become a tracking ticket for the status on getting it there, small PR by small PR plus buildbot?

@Jim.Jewett  Yes. We have got most modules passed testing locally. Now we want to get the patches upstream. So VxWorks platform can be officially supported.

New changeset aa1b8a168d8b8dc1dfc426364b7b664501302958 by pxinwr in branch 'master':
bpo-31904: Fix test_os.test_getcwd_long_path() failure for VxWorks (GH-20256)
https://github.com/python/cpython/commit/aa1b8a168d8b8dc1dfc426364b7b664501302958

New changeset a86a274b7224a5069f82c2d2cdd1f499d9c8dc22 by pxinwr in branch 'master':
bpo-31904: add shell requirement for test_pipes (GH-23489)
https://github.com/python/cpython/commit/a86a274b7224a5069f82c2d2cdd1f499d9c8dc22

New changeset 6a273fdc2a36f52fb70359149eff014f1b6b08d4 by pxinwr in branch 'master':
bpo-31904: skip some tests related to fifo on VxWorks (GH-23473)
https://github.com/python/cpython/commit/6a273fdc2a36f52fb70359149eff014f1b6b08d4

New changeset 00a6568ba37f0d815289776a51af46d0eac27384 by pxinwr in branch 'master':
bpo-31904: remove libnet dependency from detect_socket() for VxWorks (GH-23394)
https://github.com/python/cpython/commit/00a6568ba37f0d815289776a51af46d0eac27384

New changeset 1244c816d7cdfa8a26d1671cab67122a8c5271a7 by pxinwr in branch 'master':
bpo-31904: Support signal module on VxWorks (GH-23391)
https://github.com/python/cpython/commit/1244c816d7cdfa8a26d1671cab67122a8c5271a7

versions: + Python 3.10, - Python 3.8

messages: + msg315365
versions: + Python 3.8, - Python 3.7