Python 3 の移植

動作確認環境

第１世代

第２世代 (確認済みの全機種で表示に不具合あり?(白い長方形))

第３世代

第４世代

確認されている不具合

書かれていないものがあれば随時追加してください。(限定的な環境要因を除く)

動作不良モジュール

TODO

必要な差分だけがあり、かつ cpython を clone して即 make しても通る状態にする

PR 作成

多分ブランチに変更が積み重なってると思うので squash merge

分散作業を開始して CI (GitHub Actions) に乗せる

リリース

今後の PR と merge の流れ

変更してcommit, push

PR を提出し、必ず1名以上にレビューを依頼する

レビュー対応

Merge

後日 3.10 より新しいバージョンへ rebase するときのメモ

Python3の同時起動問題

背景

WindowsCEでは、同名の異なるdllを別々に読み込むことができない。

そのため、異なる時期にビルドされたpythonの

解決策

これにより、メジャー・マイナーバージョンが異なるpythonは同時に起動でき、マイクロバージョンが異なるか、ビルドが異なるpythonは同時起動できなくなった。(実行しても即時終了する)

移植の流れメモ

PythonCEが2.5と古いから微妙だな、と思って、詳しく調べた

そのパッチと、PythonCEの一部のファイルを、Python3.10.10のソースに突っ込む(実際には、2.5から3.6までの間に自然消滅していた箇所も多くあったため、ワンライナー等でPythonCEからWinCE関連のものを探しもした)

PythonCEが、疑似インタプリタをPythonコードで動かしていて、そのまま使いたくなかったため、とりあえずターミナルっぽいものを別で作る

Windowsを持っていないので、linuxのMakefileから作ることにする

Makefileやconfigureをいじくり回して、arm-mingw32ce-gccでWinCE向けのビルドができるようにする

configureとmakeとデバッグをひたすら繰り返す

事前に作っていたターミナルっぽいやつではまだうまく動いていないが(sys.std系が不完全)、DOS窓Openで、pyファイルを動かすことに成功

具体的な移植の流れ

BrainWikiでPythonCEを知る

当時は、cabインストールがなんだか怖くて入れていなかった。

しかもPython2.5だから、入れても使うのが難しいと感じていた。

そのため、PythonCEのPython3版を探したがどこにも無かった。

無いなら作ろう。

実はこの時点で、移植どころか、C言語やMakefileの経験、Pythonのビルド経験は全くと行っていいほどなかった。ただの興味。

それで、PythonCEに関することを調べまくったところ、Python3.6のタイミングで、PythonCEの名残のコードを削除するパッチが当てられていた事がわかり、さらに、PythonCEの配布ページには、Python2.5に当てるためのパッチもあり、それらをとりあえずダウンロードした。

3.10.10にした理由

確か、比較的安定そうなメジャーバージョンの当時の最新バージョンが3.10.10だったからだったと思う。(これが後に悪手となる)

パッチを当てる

当てる、といっても、パッチを具体的にどう当てたらよいかわからず、結局すべて手作業で当てた。よく考えたら、手動じゃなきゃ、2.5から3.10までの全パッチも使わないとできないので、結果オーライ？

ビルドのやり方

はじめは、PythonCEと同様に、sconsでビルドできるかなー、と、非常にのんきに考えていた。ところが、PythonCEではMicrosoft eMbedded Visual C++ 4.0をビルド時に必要としていた。scons自体も初めてだった私は、じゃあどうすれば？となった。

なかなか考えが浮かばず、とりあえず見た目からつくって動作時に達成感をより得られるようにしよう、と思い、scons等について調べる傍ら、ターミナルのようなものをtkinterで作成し、windowsapiでもどうにかそれっぽく再現した。

ゴリ押しは正義

悩んだ末、Windows依存のコード以外は共通なんだし、Makefileを魔改造したら行けるか、という結論に至った。アタマガオカシイ。ちなみにこの時点で、さすがに無茶だからうまく行かないと思っていた。

しかし、実は一つ可能性(?)があった。Makefileの作り方も知らない私は、それっぽいファイルを一通り覗いて回った。すると、config.subの中にmingw32ceがあり、これは、おそらくMakefile共通で使われるファイルなのだろうが、そんな事も知らない私はそれで少し希望を抱いた。

とりあえずビルドしてみる

ネットを彷徨って、クロスコンパイルのやり方を探した。そしてそれに則って、とりあえずconfigureとmakeを実行。案の定、「こんなマシン知るか」とエラーを吐かれる。というわけで、次に、Makefileやconfigureの作り方を調べ、Makefile.pre.inやconfigure.acにすこし記述を加え、環境変数でpthreadを無効にしたりして、どうにかcegccでのコンパイルまで持ってきた。

地獄の始まり

また、PythonCEのインタプリタの実装が、Pythonのモジュールとして作られていることに気がついたのもこのときだった。sconsのコード内に、pyファイルが依存関係として記述されているのはなぜだろうかとは思っていたが、その中身は、疑似インタプリタとPythonを仲介するプログラムだった。

コンパイルが終わり

大量の代替定義を書き終え、バイナリを生成できるまで至った。そこで問題となったのが、ファイルの構成をどうするか、である。生成物はlinuxの配置で生成されたが、使用環境はWindows系なので、変えて動くのかわからなかった。そこで、Python公式が配布しているembeddable packageの構成と、PythonCEの構成を参考にして、実機に移し、動かしてみた。

もう一つの難所

さて、実機での動作確認に映るのだが、最初は何も起こらず終了した。調べてみると、(少なくともPW-SH7では)CryptAPIの関数が削られていたため、それの代替関数を作った。その後、初期に一番多かったのが、クラッシュだった。c初心者のコードなので、間違いやミスが膨大にある。しばらくはその修正に追われた。具体的な修正方法だが、winapiが関係ない関数等は、linux上で動くよう少しだけ関数のコードを改変し、コンパイルして実行するというものと、winapiに関係するものは、OutputDebugStringWでエラー箇所を突き詰めていくというものだった。このようにして、なんとかエラーを減らしていった。

Hello World

(not yet)

ビルド方法

64bitのDebianで、CeGCCとpython3を導入

ソース直下のtcl8.4.3をBrainのルート直下に、tcl84.dll、tk84.dll、celib.dllを\Windows直下にコピーすると、tkinterも動作する。