Github: https://github.com/kayhayen/Nuitka

Nuitkaの公式ミラーhttp://nuitka.netから

Nuitkaユーザーマニュアル

内容

概要

この文書は、あなたがNuitkaを使用すること、その使用例を理解すること、期待できることを確認すること、ライセンス、要件、クレジットなどに興味がある場合には、最初に読むことをお勧めします。

NuitkaはPythonコンパイラです。これは、Pythonインタプリタのシームレスな置換または拡張であり、CPython 2.6,2.7,3.2,3.3,3.4,3.5、および3.6にあるすべての構文をコンパイルします。次に、コンパイルされていないコードとコンパイルされたコードを極めて互換性のある方法で一緒に実行します。

すべてのPythonライブラリモジュールまたはすべての拡張モジュールを自由に使用できます。これは、PythonをCレベルのプログラムに変換し、その後、 “libpython”を使ってCPythonと同じように実行します。すべての最適化は、不要なオーバーヘッドを避けることを目的としています。標準的なPythonのすべてのバグがエミュレートされているわけではありません。たとえ完全なエラーメッセージが出されても、それを無効にする完全な互換モードがあります。

使用法

要件

Cコンパイラ：C11をサポートするコンパイラ、またはC ++ 03 [1]をサポートするコンパイラが必要です。

現在、これらのコンパイラのいずれかを使用する必要があります。
- 少なくともバージョン5.1の “ gcc`コンパイラ、または代替としてのバージョン4.4以上のg++コンパイラです。
- MacOS XまたはFreeBSD上のclangコンパイラ、LLVMバージョン3.2以降。
- Windows上のMinGW64 [2] C11コンパイラ、理想的にはgcc 5.1以上をベースにしたコンパイラ。あるいは、代わりに少なくともバージョン4.4のC ++コンパイラ。
- Windows [3]上のVisual Studio 2017以降では、古いバージョンが動作する可能性がありますが、正式にはサポートされていません。最高の結果を得るために英語のパックを使用するよう設定します（Nuitkaはガベージ出力を除外しますが、その言語のみに適用されます）。
Python：バージョン2.6,5.7,3.2,3.3,3.4,3.5,3.6（はい、しかし以下を読んでください）

Python3ではなく、3.2,3.3、および3.4ではコンパイル時の依存関係として他のPythonのバージョンが必要です

Nuitka自体はすべての言及バージョンと完全に互換性があり、Sconsはそうではありません。

これらのバージョンでは、コンパイル時にのみPython2またはPython3.5もインストールする必要があります。これは、Nuitkaと同じPythonバージョンをサポートしていないScons（Cコンパイルを調整します）で使用するためのものです。

他のマシンへの移動

作成されたバイナリは、Pythonのインストールとは独立して、 --standaloneオプションで実行可能にすることができます。

Linuxでもバイナリファイル名の接尾辞 “.exe”

作成されたバイナリには “.exe”というサフィックスがあり、これを自由に削除することができます。これはLinuxバイナリです。サフィックスは、元のスクリプト名とバイナリ名が衝突しないことを確認するだけです。

それはCPythonまたはAnaCondaでなければなりません

Nuitkaを実行するには、標準的なPythonの実装である “CPython”が必要です。なぜなら、Nuitkaを使用することと密接に結びついているからです。

Windowsでは、いわゆる “WinPython”と “AnaConda”ディストリビューションは動作しますが、アクセラレーションモードでは問題が発生します。スタンドアローンモードと拡張モジュールまたはパッケージの作成は動作します。アクセラレーションモードでは、 “PythonXX.DLL”をその横にコピーする必要があります。
オペレーティングシステム：Linux、FreeBSD、NetBSD、MacOS X、Windows（32/64ビット）。

他は同様に働くかもしれません。移植性は概ね良好であると予想されるが、例えばSconsの使用法を適合させる必要があるかもしれない。
アーキテクチャ：x86、x86_64（amd64）、アーム

Nuitkaは一般的にハードウェアの仕様を使用していないため、他のアーキテクチャもそのまま使用できます。これらは、テストされ、良いことが分かっているものです。フィードバックは大歓迎です。 Debianがサポートしているアーキテクチャは、一般的には優れていると評価され、テストされています。

[1]	このC11のサポートは、gcc 5以上またはclangで与えられます。 MSVCコンパイラはまだそれをしません。しかし、回避策として、C ++ 03の言語標準はC11と非常に重複しており、Cコンパイラが古すぎる場所の代わりに使用されます。以前はNuitkaがC ++コンパイラを要求していましたが、変更されました。

[2]	MinGW64をhttp://mingw-w64.org/からダウンロードし、Pythonにマッチする64ビットまたは32ビットを選択してください。使用するPythonの選択肢がある場合は、MinGW64と64ビットPythonの両方を使用してください。それを “C：MinGW64″または “MinGW64″（同じディスクルート）にインストールして、自動的に探します。

[3]	http://www.visualstudio.com/en-us/downloads/download-visual-studio-vs.aspxから無料でダウンロードしてください（Express Editionはうまく動作します）。最新版がお勧めです。古いバージョンを使用する必要はありませんが、実際には動作しない可能性があります。

コマンドライン

環境変数の変更は必要ありませんが、最も注目すべきことに、NuitkaのためにPYTHONPATHをまったく使用する必要はありません。環境を変更することなく、 nuitka-runスクリプトとnuitka-runスクリプトを直接実行するだけです。便宜上、 PATH binディレクトリを追加することもできますが、その手順はオプションです。

Nuitkaには、できることを出力するための--helpオプションがあります：

nuitka --help

nuitka-runコマンドはnuitkaと同じですが、デフォルトは異なります。 Pythonスクリプトをコンパイルして直接実行しようとします：

nuitka-run --help

異なるこれらのオプションは--runであり、作成されたバイナリの最初の非オプションの後に引数を渡すので、プレーンなpythonやり方と多少似ています。

ライセンス

Nuitkaは、Apache License、Version 2.0のライセンスを受けています。あなたは、ライセンスに従わずに使用することはできません。

お客様は、 http://www.apache.org/licenses/LICENSE-2.0でライセンスのコピーを入手することができます

適用法または書面による合意が必要な場合を除き、本ライセンスに基づいて配布されるソフトウェアは、明示的または黙示的にいかなる種類の保証または条件もなく「現状有姿」で配布されます。ライセンスに基づいて許可および制限を規定する特定の言語については、ライセンスを参照してください。

ユースケース

ユースケース1 – すべてのモジュールが埋め込まれたプログラムコンパイル

メインプログラムである1つのファイルだけでなく、プログラム全体を再帰的にコンパイルする場合は、次のようにします。

nuitka --recurse-all program.py

注意

--recurse-allよりも細かい制御があります。 nuitka --helpの出力を考えてみましょう。

PYTHONPATHを介して通常のインポート文の後で再帰的に見つけられないプラグインディレクトリ（推奨される方法）がある場合は、いつでも指定のディレクトリも実行可能ファイルに含める必要があります：

nuitka --recurse-all --recurse-directory=plugin_dir program.py

注意

動的なインポートを行わない場合は、コンパイル時にPYTHONPATHを設定するだけで、通常どおりに十分です。

--recurse-directoryは、Nuitkaが予測できない__import__()呼び出しを行う場合にのみ使用します。たとえば、コマンドラインパラメータに依存するためです。 Nuitkaはこれらについて警告し、オプションを指しています。

注意

生成されるバイナリは、CPythonと使用されるC拡張モジュールに依存します。

別のマシンにコピーできるようにするには、– --standaloneを使用して、作成したprogram.distディレクトリをコピーし、内部にprogram.exeを実行します。

注意

結果のファイル名は、すべてのプラットフォームでprogram.exeになります。つまり、Windows以外の環境では実行されません！しかし、 programをコンパイルすると、上書きしたり、どちらがコンパイルされた形式であるのか、どちらがコンパイルされていないのかはわかりません。

ユースケース2 – 拡張モジュールのコンパイル

単一の拡張モジュールをコンパイルしたい場合は、これだけです。

nuitka --module some_module.py

結果ファイル “some_module.so”は “some_module.py”の代わりに使用できます。それは読者に運動として残されていますが、両方が存在する場合はどうなりますか。

注意

オプション--recurse-allと他のバリアントも同様に動作します。

ユースケース3 – パッケージのコンパイル

パッケージ全体をコンパイルし、すべてのモジュールを埋め込む必要がある場合は、それも実行可能ですが、Nuitkaを次のように使用してください：

nuitka --module some_package --recurse-directory=some_package

注意

パッケージディレクトリへの再帰を手動で提供する必要があります。そうでない場合、パッケージは空です。パッケージ内にあるデータファイルはまだ埋め込まれません。

どこへ行くか

このプロジェクトはまだ完成していないことを忘れないでください。 CPythonテストスイートはほぼ完璧に動作しますが、さらに多くの作業が必要です。より多くの最適化を行うことができます。やってみて。

メーリングリストに登録する

比較的少量のメーリングリストを購読するには、メーリングリストのページをご覧ください。 Nuitkaのすべての問題はここで議論することができます。また、これは何が来ているの情報を残しておく場所です。

問題やバグを報告する

問題、バグ、またはアイデアが発生した場合は、 Nuitkaバグトラッカーにアクセスして報告してください。

バグを報告するためのベストプラクティス：

あなたのレポートには、基礎となるPythonバージョンのための以下の情報が含まれています。これを簡単にコピーしてレポートに貼り付けることができます。
```
nuitka --version
```
あなたの例を最小限にするようにしてください。つまり、できるだけ問題に寄与しないコードを削除しようとします。理想的には、プログラムがコンパイルされているかネイティブで実行されているときに、異なる結果のprintを使用して、問題を示す小さな再現プログラムを思いついてください。
疑似的に問題が発生した場合（毎回ではなく）、環境変数PYTHONHASHSEEDを0に設定して、ハッシュのランダム化を無効にしてください。問題が解決しない場合は、毎回ハッシュシード値を1ずつ増やしてみてください。
作成したコードをレポートに含めないでください。適切な入力が与えられれば、それは重複しているので、PythonやNuitkaのソースを変更して再実行することはできません。

Twitterで私に従ってください

Nuitkaのアナウンスや興味深いものはTwitterアカウントで指摘されているが、明らかに詳細はない。 @ケイハイエン。

私はTwitter経由でNuitkaの質問に答えません。

警告の言葉

このソフトウェアは慎重に使用することを検討してください。リリース前に多くのテストが適用されていますが、事態は潜在的に壊れています。あなたのフィードバックとNuitkaへのパッチは大歓迎です。

特に、報告されていることがあれば、何かがうまくいかないことが分かった場合、プロジェクトが現時点で行われていないことが分かっているため、未知のバグに遭遇したことが間違いないでしょう。

Nuitkaに参加する

Nuitkaの開発に加わり、すべてのマイナーチェンジおよび主要な方法でプロジェクトを完了するのを歓迎します。

Nuitkaの開発はgitで行われます。私たちは現在、次の3つのブランチを持っています

マスター：

このブランチには、バグの修正のみが行われる安定版リリースが含まれています。常に働き、サポートされています。
開発する：

このブランチには継続的な開発が含まれています。時には回帰もほとんどなく、新機能も含まれていることがあります。このブランチでは統合作業が行われますが、新機能はフィーチャーブランチで開発される可能性があります。
工場：

このブランチには、未完成の作業と不完全な作業が含まれています。それは非常に頻繁にgit rebaseと私のブランチを開発するための私の仕事が最初に生きる公のステージング地です。これはテストのためのものであり、あなた自身の開発の基礎となることを推奨します。それを更新すると、頻繁にマージ競合が発生します。単にgit reset --hard origin/factoryをgit reset --hard origin/factoryしてそれらを解決し、最新のバージョンに切り替えます。

注意

私はパッチファイル、git形式のパッチキュー（ git format-patch originコマンドを使用する）、またはgitがソーシャルコードプラットフォームを利用するのを好む場合は受け入れます。

私は統合作業を行います。任意の時点であなたの仕事を「マスター」または「開発」に基づいている場合は、私は必要な再ベースを行い、あなたの作者をそのまま維持します。

注意

開発者マニュアルは、コーディング規則、使用されるブランチモデル、機能ブランチと修正リリース、Nuitkaデザインなどについて説明します。寄稿者になるためにそれを読むことを検討してください。この文書はNuitkaユーザーを対象としています。

寄付

Nuitkaを直接には手伝ってはいけないと思っていますが、まだサポートしたいと思っている場合は、寄付をしてこの方法を助けることを検討してください。

サポートされていない機能

コードオブジェクトの`co_code`属性

コードオブジェクトは、ネイティブコンパイルされた関数のために空です。 Nuitkaのコンパイルされた関数オブジェクトにはバイトコードがないので、それを提供する方法はありません。

最適化

コンスタントフォールディング

最適化の最も重要な形態は、定数フォールディングです。これはコンパイル時に操作を完全に予測できるときです。現在、Nuitkaはいくつかの組み込み関数に対してこれらを行っています（ただし、まだこれを見ている人はまったく歓迎されません）。バイナリ/単項演算と比較のためにこれを行います。

現在認識されている定数：

5 + 6     # binary operations
not 7     # unary operations
5 < 6     # comparisons
range(3)  # built-ins

リテラルは定数の明白なソースですが、定数伝播や関数インライン化のような他の最適化ステップも可能です。だから、これを過小評価すべきではなく、最適化を成功させるための非常に重要なステップです。定数を生成するすべてのオプションは、生成されるコードの品質に大きな影響を与える可能性があります。

状態

定数のフォールディングは実装されていると見なされますが、可能性のあるすべてのケースがキャッチされないという点で不完全かもしれません。 Nuitkaの入力が定数で、折り畳まれていない操作を見つけたら、バグとして報告してください。

一定の伝播

最適化の中核には、実行時の変数の値と代入の予測を決定しようとする試みがあります。入力が定数か類似の値かを判断します。モジュール変数アクセス、高価な操作などの式は、関数スコープのモジュール全体で一定であり、モジュール変数のルックアップが何もない、または何も繰り返されていない必要があります。

たとえば、モジュール属性__name__を読んでいる可能性が高いと考えてください。その値は、コンパイル時に知られている定数文字列に予測できます。これは定数フォールディングの入力として使用できます。

if __name__ == "__main__":
   # Your test code might be here
   use_something_not_use_by_program()

状態

modules属性から、 __name__だけが現在実際に最適化されています。少なくとも__doc__でも可能です。 SSAがモジュール変数に拡張されると、将来的には改善される可能性があります。

ビルトイン名の参照

モジュールレベルの読み取り専用変数として使用される場合は、組み込みの例外名参照も最適化されます。

try:
   something()
except ValueError: # The ValueError is a slow global name lookup normally.
   pass

状態

これは組み込みのすべての名前で機能します。そのような名前に割り当てが行われたり、ローカルであったりすると、もちろん完了しません。

ビルトインコール予測

type 、 len 、 rangeなどの組み込み呼び出しでは、コンパイル時に結果を予測することが可能です。一定の入力に対しては、結果の値はNuitkaによって事前計算されることが多い。結果や例外が発生したかどうかを簡単に判断し、組み込み呼び出しをその値に置き換えて、より一定のフォールディングまたはコードパスの縮小を可能にします。

type("string") # predictable result, builtin type str.
len([1, 2])    # predictable result
range(3, 9, 2) # predictable result
range(3, 9, 0) # predictable exception, range raises due to 0.

状態

ビルトインコール予測は実装されていると見なされます。コンパイル時に呼び出しをエミュレートし、結果を使用したり、例外を送出したりすることができます。しかし、私たちはまだそこにあるすべての組み込み関数をカバーしているわけではありません。

場合によっては、結果が大きいときに組み込みの結果を予測してはいけません。 range()コールは、結果をバイナリに含めるには大きすぎる値を与えることがあります。その後、それは行われません。

range( 100000 ) # We do not want this one to be expanded

状態

これは主に実装されていると考えられます。あらかじめ計算されているビルトインのバグを報告してください。コンパイル時にNuitkaが特定の値で計算してはいけません。

条件文の予測

条件文については、予測可能な条件のために、一部の分岐が実行されないことがあります。このような場合、ブランチは取得されず、条件チェックは削除されます。

これは、通常、次のようなコードを予測できます。

if __name__ == "__main__":
   # Your test code might be here
   use_something_not_use_by_program()

または

if False:
   # Your deactivated code might be here

また、いくつかのブランチが削除されると、他のものがより予測可能になる可能性があるため、他の最適化を可能にするため、一定の伝搬が有効です。

削除されたすべてのブランチは最適化を行います。一部のコードブランチを削除すると、アクセスパターンがよりフレンドリーになる可能性があります。たとえば、関数が削除されたブランチでのみ呼び出されるとします。それを完全に取り除くことは可能かもしれません、そして、それは他の結果も持っているかもしれません。

状態

これは実装されていると考えられますが、最大限の利益のために、コンパイル時に多くの定数を決定する必要があります。

例外伝播

コンパイル時に決定される例外については、単に例外を発生させる式があります。これらは、潜在的な「副作用」、すなわち発生前に実行された式の一部を収集して、それでも実行する必要がある場合に、上方に伝播させることができます。

次のコードを考えてみましょう：

print side_effect_having() + (1 / 0)
print something_else()

(1 / 0) ZeroDivisionError (1 / 0)は、 +演算によって伝播されるZeroDivisionError例外を発生させると予測できます。その部分は普通の伝播と同じです。

side_effect_having（）コールは保持される必要がありprintが、 print文は明示的なraiseにはなりません。ステートメントシーケンスは中止される可能性があります。そのため、 something_else呼び出しでコード生成や考慮が必要なくなります。

そのために、Nuitkaは例外を発生させ、いわゆる “side_effects”式でラップされた特殊ノードを使用しますが、値を持つ式としてコードで使用することもできます。

状態

例外の伝播はほとんどが実装されていますが、あらゆる種類の操作で処理する必要があります。仕事の進展や事例が出現すると、カバレッジは拡大されます。動作していないサンプルを使ってバグレポートを生成してください。

例外スコープの削減

次のコードを考えてみましょう：

try:
    b = 8
    print range(3, b, 0)
    print "Will not be executed"
except ValueError, e:
    print e

tryブロックは必要以上に大きくなります。ステートメントb = 8は、 ValueErrorを発生させることはできません。そのようなものとして、リスクのないtryの外側に移動することができます。

b = 8
try:
    print range(3, b, 0)
    print "Will not be executed"
except ValueError as e:
    print e

状態

これは完了したとみなされます。すべての種類の操作について、例外が発生する可能性がある場合はトレースします。しかし、 ValueErrorは何ができ、何ができないのかは正しく追跡できません。

例外ブロックインライン化

例外の伝播によって、このコードを変換することが可能になります。

try:
    b = 8
    print range(3, b, 0)
    print "Will not be executed"
except ValueError, e:
    print e

try:
    raise ValueError, "range() step argument must not be zero"
except ValueError, e:
    print e

これは、例外の発生とキャッチを避けることで減らすことができます。

e = ValueError( "range() step argument must not be zero" )
print e

状態

これはまだ実装されていません。

空の分岐の削除

効果のないコードのみを含むループや条件文では、構造全体を削除することが可能です。

for i in range(1000):
    pass

ループを削除することができます。最大では、変数iを999割り当てることを考慮する必要があります。

状態

これはまだ実装されていません。イテレータとその副作用、ループ値、終了条件を追跡する必要があるためです。あまりにもまだ、しかし我々はそこに着くでしょう。

もう一つの例：

if side_effect_free:
   pass

評価が不要なので、条件チェックはこの場合は削除する必要があります。 side_effect_freeに副作用がないと予測するのは難しいかもしれませんが、何回も可能です。

状態

これは実装されていると考えられます。条件文の性質は、両方のブランチが空で、条件のみが評価され、真（例外を発生させる可能性がある場合）がチェックされている場合に削除されます。

予測の開梱

シーケンスへの代入の右辺の長さを予測できる場合、アンパックは複数の代入で置き換えることができます。

a, b, c = 1, side_effect_free(), 3

a = 1
b = side_effect_free()
c = 3

これはもちろん、割り当て対象を構築しているときに左側が例外を発生させることができない場合にのみ、本当に安全です。

式は例外を発生させるかどうかを予測する能力がまだないので、これを今では行いますが、定数に対してのみ行います。

状態

まだ実装されていません。タプル上の反復を解くことで、私たちは自分自身を作り出しました。我々はまだそこにはいないが、我々はそこに着くだろう。

組み込み型推論

in xrange()やin xrange()ようなin xrange()使用すると、イテレータが何を行い、それを表すかを知ることができるので、イテレータのユーザは代わりにイテレータを使用できます。

私はそれを考慮する：

for i in xrange(1000):
    something(i)

xrange(1000)を、整数をより効率的にループする特殊なクラスのオブジェクトに変換することができます。 iがそこから割り当てられるだけの場合、これは専用のクラスのための良いケースかもしれません。

状態

将来の仕事は始まったことさえありません。

より迅速な関数呼び出し

ファンクションは、パラメータ解析とtp_callインタフェースが実際のファンクションコードとは別のものになるように構造化されています。この方法で呼び出しを最適化することができます。 1つの問題は、評価の順序が異なることです。

def f(a, b, c):
    return a, b, c

f(c = get1(), b = get2(), a = get3())

これは、最初のget1()を評価し、次にget1() 、そしてget2()のみを評価し、これらの値を使って関数呼び出しを行う必要があります。

したがって、実際の呼び出しを行う前に、 get1() 、 get2() 、およびget3()への呼び出しの再順序付けを避けるために、パラメータのステージングが必要です。

状態

始まったことさえありません。辞書を使用して関数を呼び出すことを避け、代わりに一時変数を使用する再定式化は、この種のパラメータ分析を行うと比較的単純です。

反復されたコンテナタイプの降下

場合によっては、 list定数へのアクセスが代わりにtuple定数になることがあります。

それを考慮する：

for x in [a, b, c]:
    something(x)

これに最適化することができます：

for x in (a, b, c):
     something(x)

これは、 tupleが明らかに不変であるのに対し、 listはそれをアサートするためのチェックが必要であるため、よりシンプルで高速なコードが生成され、必要なチェックが少なくなります。これはセットでも可能です。

状態

実装され、非定数の場合でも動作します。一般的に有用になるために他の最適化が必要であり、それ自体が他の最適化を可能にするのに役立つでしょう。これは、例えば、タプル上の反復のみを処理し、セットを気にすることはありません。

理論的には、同様のことがdictでも可能です。後では、一時的な値を導入しないで実行の順序を維持することは重要ではありません。これらの型の純粋な定数についても同じことが行われ、反復されるとtuple値に変更されます。

クレジット

Nuitkaへの貢献者

Nuitkaへの彼らの評価の高い貢献のためにこれらの個人に感謝します。寄稿者は、クローズソースの場合でもNuitkaを独自のコードで使用するためのライセンスを持っています。

順序は時間でソートされます。

Li Xuan Ji：一般的な移植性の問題と環境変数の設定の強化に役立つパッチ。
Nicolas Dumazet：参照カウントの問題を発見して固定し、パッケージをimport 、英語の一部を改善し、一般的にコードの貢献度を高め、コード生成のTODOを解決し、ツリービルドのクリーンアップ、コアの処理を行いました。
Khalid Abu Bakr：MinGWとWindowsをサポートするためのパッチを提出し、問題をデバッグし、LinuxからWindowsへのMinGWのクロスコンパイルを手助けしました。これはかなり難しいものでした。
Liu Zhenhai：Windowsサポートのために提出されたパッチ。インラインSconsコピーはWindows上で実際に動作します。また、インポート関連のバグも報告され、テストや情報を通じてWindowsポートをより使いやすくするのに役立ちました。
Christopher Tott：Windows用のパッチ、一般的なものと構造的なクリーンアップを提出しました。
Pete Hunt：MacOS Xサポートのために提出されたパッチ。
“ownssh”：組み込みのモジュールガーディングのために提出されたパッチであり、高品質のバグレポートを作成するための多大な努力をしました。また、初期の「スタンドアロン」モードの実装が彼によって作成されました。
Juan Carlos Paco： Nuitka用のNinja IDEプラグインの作成者であるNuitka GUIの作成者が提出したクリーンアップパッチ。
“dr。Equivalent”：Nuitkaロゴを提出しました。
Johan Holmberg：MacOS XでPython3をサポートするための提出されたパッチ
Umbra：Windowsのポートをより使いやすくし、ユーザーが提供するアプリケーションアイコンを追加するだけでなく、大規模な定数やコンソールアプリケーションのMSVCサポートを追加しました。
David Cortesi：QtのPython3スタンドアロンサポートのために、MacOSポートをより使いやすくするために提出されたパッチとテストケース。
Andrew Leech： “-m nuitka”を使用してコンパイラを呼び出すことを許可するgithubプルリクエストを提出しました。また、 “bist_nuitka”を改善し、登録を行うためのリクエストを引き出します。

Nuitkaが使用したプロジェクト

CPythonプロジェクト

Nuitkaの拠点であるCPythonをお寄せいただきありがとうございます。私たちはそれなしでは何もありません。
GCCプロジェクト

最高のコンパイラスイートだけでなく、Nuitkaを根絶するのに役立つC ++ 11のサポートに感謝します。あなたのコンパイラは、Nuitkaにとって最初に使用可能で、少しの労力で使用できました。
Sconsプロジェクト

困難な点に対処し、ビルド結果を作るためのPython環境を提供してくれてありがとう。これは、Nuitkaとその可能性が残る可能性の高い依存関係に完璧にフィットしています。
valgrindプロジェクト

幸運なことに、Valgrindを使用して、何かがノイズなしで実際の改善であるかどうかを判断できます。また、比較の際に実際に何が起きているのかを判断することも役に立ちます。
NeuroDebianプロジェクト

DebianとスポンサーのYaroslav HalchenkoがすべてのUbuntuバージョン用のパッケージを提供するために使用するビルドインフラストラクチャをホストしてくれてありがとう。
openSUSEビルドサービス

この素晴らしいサービスをご利用いただき、ありがとうございます。多種多様なプラットフォーム用のRPMを提供し、リリース時点ですぐに利用できるようにしています。
MinGW64プロジェクト

gccをWindowsに移植してくれてありがとう。これにより、比較的わずかな労力でNuitkaの移植性が可能になりました。
Buildbotプロジェクト

Windows上で動作し、Pythonコードで記述され、構成された継続的な統合フレームワークを簡単に導入して使用することに感謝します。これにより、リリース時間のずっと前にNuitkaテストを実行することができます。
Redbaronプロジェクト

Pythonのリファクタリングのための白いスペースを保存し、使いやすいツールワークを作成してくれてありがとう。これにより、私たちは、好みに応じて自動的にPythonコードをフォーマットし、グローバルな変更を簡単に行うことができます。
isortプロジェクト

素敵なインポートオーダーをとても簡単にしてくれてありがとう。これにより、あなたのIDEにそれをさせて後でクリーンアップできるようになります。

このマニュアルの更新

この文書はRESTで書かれています。これは、ASCII形式で表示されますが、PDF形式またはHTML形式の文書を生成するために使用されます。

現在のソースはhttp://nuitka.net/gitweb/?p=Nuitka.git;a=blob_plain;f=README.rstにあります。

現在のPDFはhttp://nuitka.net/doc/README.pdfです。

Nuitka – Nuitkaの公式ミラーから

Nuitkaユーザーマニュアル