osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] VxWorks and cpython?


Le jeu. 10 janv. 2019 ? 17:54, Kuhl, Brian <brian.kuhl at 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.