Hi Victor, I think we can come up with some sort of strategy that will work for everyone. I'll ask about the SSH access; and if that runs up against a corporate roadblock, I will explore some other alternative.
Is there a good place to document "Python on VxWorks" ? The changes to Python are not large, I've kept the pull request from last year's POC active. The changed files provide a good summary of the scope. https://github.com/python/cpython/pull/4184/files However, based on the POC we've gone back and improved VxWorks, so the some of the uglier bits, in libraries like submodule, won't be needed. These will be in the next release of VxWorks. However we let automake and setup.py do much of the work for us, so where VxWorks does not have support for something, it's not obvious. A public document would go a long way to filling in those details, something much more detailed than my glib "VxWorks is almost POSIX" in the pull request. Other challenges; * VxWorks is cross-compiled on both Linux and Windows. ( currently with clang and gcc) * Supported on ARM, PowerPC and Intel processors * 32bit and 64bit builds * A constantly evolving set of reference boards (or BSPs) https://marketplace.windriver.com/index.php?bsp&on=list&type=platform&value=VxWorks:%207%20-%20Wind%20River%20Workbench%204.0 I don't think we need a buildbot for every board. I'm thinking a 1/2 dozen to cover ARM, PPC and IA with both a 32bit and 64 bit build? We have a bit of chicken and egg problem right now, a buildbot will always fail until there's some basic VxWorks support added. Do we set them up, and just let them fail, till enough PRs are accepted to make it build? Brian > -----Original Message----- > From: Victor Stinner [mailto:vstin...@redhat.com] > Sent: Wednesday, January 09, 2019 6:43 PM > To: Christian Heimes > Cc: Guido van Rossum; Kuhl, Brian; python-dev@python.org > Subject: Re: [Python-Dev] VxWorks and cpython? > > Le mer. 9 janv. 2019 à 18:16, Christian Heimes <christ...@python.org> a écrit > : > > It's a PEP. The process and expectations for platform are explained in > > PEP 11, https://www.python.org/dev/peps/pep-0011/ > > I also wrote some information in my website: > https://pythondev.readthedocs.io/platforms.html > > > If possible it would also be helpful to get SSH access to some VxWorks > > machines for core devs. I know that Victor likes to dig into rare > > corner cases and help to debug exotic platforms. > > The best case to get a full support is to have one core developer responsible > of > handling all bugs specific to the platform. > > As a core developer, I'm never comfortable to merge a change specific to a > platform if I'm not able to validate it manually myself. I trust no one, not > even > myself (I know well that I do frequently mistakes!), so I prefer to always > double > check changes before merging them ;-) > > In the meanwhile, I would say that we can only offer "best effort" > support. Fix reports bugs and do our best in our limited time. > > Someone has to take the work done to port Python on VxWorks and write small > pull requests. These PRs should be reviewed one by one to make sure that it's > the correct way to fix an issue. Be prepared that it can take several months > even > if all these changes look obvious to *you*. Core developers have limited time > and many prefer to focus on the platforms that they are using, not worry about > a platform they never heard about... I can have a look at such PRs. > > It would also help to have a documentation somewhere about "Python on > VxWorks". Pointers to VxWorks (general info, developers info), pointers to > your > port, current status of the port, etc. > > Victor > -- > Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
