Le jeu. 10 janv. 2019 à 17:54, Kuhl, Brian <brian.k...@windriver.com> a écrit : > Is there a good place to document "Python on VxWorks" ?
Anywhere. If you don't know, you might use https://wiki.python.org/moin/ ... But I'm not sure that the wiki is still widely used. Many pages may be outdated. > 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 That's a giant PR. Sorry, I'm unable to review that. Usually, I simply ignore such PR. > 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. Cross-compilation is complex. So yeah, any documentation is more than welcome. Many people are still fighting to try to get a working Python on Android... My notes: https://pythondev.readthedocs.io/android.html (is there still someone working on that?) > Other challenges; > * VxWorks is cross-compiled on both Linux and Windows. ( currently with clang > and gcc) > * Supported on ARM, PowerPC and Intel processors I don't think that it should be an issue for Python. Very few parts of CPython are architecture specific. I'm aware of ctypes which is more or less optional. ctypes rely on libffi which supports a wide range of architectures. > * 32bit and 64bit builds We have a wide range of 32 and 64 bits buildbot workers. I don't expect any issue here. Which C compiler do you use? > * 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'm not sure how it's supposed to impact Python? > 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. No please. A *single* buildbot worker in total is enough. When you will have a very good support and a full test suite coverage, we can discuss about adding more flavors. > Do we set them up, and just let them fail, till enough PRs are accepted to > make it build? Multiple buildbot workers are failing since many years. *I* would prefer to see the full test suite passing (even if some tests are skipped on your platform) before adding a buildbot, but it seems like some people have a different opinion on that. For example, there is an AIX buildbot and some tests are still failing (it was always red, failing, no?). You're right that it's a chicken-and-egg issue, except that we don't have a very strong policy for buildbots. Note: I cannot promise that I will review your PR. I can only promise that I will have a look :-) VxWorks is not really a priority for me. (I prefer to not give false promise here.) 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
