最後にC ++でPythonのモジュールを作成したのは2004年でした。 死産のライブラリ(残念ながら私のためではありません)ライブラリ(私は愚かにも給与のためにスキルを売りました)。 当然、スキルは固定されていません。 SWIGはオブジェクトインターフェイスを必要とし、「ペン」で書くと壊れたため、 SWIGが私の作業を非常に促進したことを覚えています。 私の記憶は専門的です-つまり、選択的で短いため、最初にジャンプしなければなりませんでした。
この記事は、WindowsでのPython用のSWIGのセットアップについてのみ説明しています。 SWIGを使用してC / C ++でモジュールを作成することは、すべてをセットアップするよりもはるかに簡単です(ところで、これは現代のプログラミングのパラダイムであるという印象があります)。
まず、Yandexに登りました。 壮大な失敗-すべてのヒントと回避策は3年前のものです。 それらに続いて、ソースからpythonをビルドするために絶対に不必要な手順を踏む必要がありました。 この記事には不必要な手順はありませんが、Pythonは問題なく動作します。 ただし、収集する場合は、「箱入り」配信からファイルInclude / pycohfig.hを取り出して、静かに組み立てられたバージョンに入れておくと便利です。
良いニュース。 Python 2.6+は彼によって構築されているため、 Microsoft Visual C ++ Express Edition 2008を使用してモジュールを構築できます。 これに先立ち、Pythonをソースからコンパイルするか、苔で覆われたVC ++ 7.0、さらには6.0をコンパイルする必要がありました。 さらに良いニュースは、モジュールをMinGWでコンパイルできることです。 ちなみに? Strawberry Perlに「含まれる」テストモジュールgccをコンパイルしました(古代のpython-pearl戦争を思い出すと、かなり皮肉です)。 それがPathの最初のgccだからです。
そのため、SWIGの例を取り上げて、モジュールに変換する必要があります。 これを行うには2つの方法があります。
ただし、最初に、Windows(swigwin-2.0.4)でビルドされたSWIGをインストールし、PATHに登録する必要があります。 ユースケースには付属しています。
方法1:Visual C ++
環境変数を設定する必要があります。
PYTHON_INCLUDE = C:\ Python \含める PYTHON_LIB = C:\ Python \ Libs \ python27.lib
その後、だまされます-ソリューション(.sln)とプロジェクトが既に作成されている既製のサンプルの1つを取ります。 そして、それに基づいて冷静にモジュールを作成します。 たとえば、
SWIG\Examples\python\class\exmple.sln
ます。
examples.i
、
examples.cxx
および
examples_wrap.cxx
名前をそれぞれ
mymodule.i
、
mymodule.cxx
および
mymodule_wrap.cxx
ます。
経験が始まったばかりなので、すべてがうまく機能します。
より腐食性の強い仲間のために、英語の
- 新しいプロジェクトを作成してWindows DLLを作成します
- クラス/関数用にファイル
my_module.cxx
(または.c)を作成し、インターフェースの説明用にmy_module.i
を作成します。 そして、my_module_wrap.cxx
を規定します(ただし、作成しません)。 もちろん、最初の2つのファイルは同じ例から切り取りましたが、たとえば、 Wikipediaから取得することもできます)
- 環境
my_module.i
で、プロパティ( カスタムビルドセットアップ )セットで選択します 。
- コマンドライン :swig.exe -c++ -python $(InputPath)
- 出力 :$(InputName)_wrap.cxx
(Cプロジェクトの場合、最初の場合は-c++
スイッチを指定する必要はありません.cxx
番目の場合は.cxx
拡張子(.cで十分です)。)
その結果、インターフェイスファイルmy_module.i
からファイルmy_module_wrap.c(xx)
を作成します。
- 次に、Pythonヘッダーの場所を設定する必要があります。 プロジェクトのプロパティで、 構成プロパティ” / C ++を選択し、 追加のインクルードディレクトリを
$(PYTHON_INCLUDE)
設定します(彼に何か質問しましたか?
- さらに、リンカー(リンカー)のプロパティの計画について:
- 入力»追加の依存関係 :"$(PYTHON_LIB)"
- 一般»出力ファイル :$(ProjectDir)\_$(ProjectName).pyd
前者の場合、引用符は傷つきません。後者の場合、下線に注意してください。 なぜですか-以下で説明します。
- プロジェクトをビルドできます。 リリース構成に切り替えることを忘れないでください。 デバッグを使用するには、ソースからpythonをビルドする必要がありますが、必要ですか?
- 利益
方法2:distutils
Python 2.7は、 distutilsを使用してモジュールを収集するために既に投獄されています(以前のバージョンでは、 3キログラムのシャーマニズムが必要でした)。 同時に、前述の(夜間ではなく)MVC 2008と無料のMinGWの両方を使用できます。
道に沿って私たちを待っている小さな熊手について、私は額をなでます、今私は教えます。
繰り返しますが、SWIGの例を使用して非人間的な実験を設定します。 そのため、
SWIG/examples/classes
ディレクトリで、
setup.py
作成し
setup.py
# -*- coding: utf-8 -*- import distutils from distutils.core import setup, Extension setup(name = "Simple example from the SWIG website", version = "0.007", ext_modules = [Extension( "_example", # : ["example.i","example.cxx"], swig_opts=['-threads', '-c++'], # : swig )] );
最初のレーキ。
下線。 指定しない場合、エラー
LINK : error LNK2001: unresolved external symbol initexample
ます。
それはどこから成長しますか?
Pythonは、「手動」でモジュールを作成するときに、コンパイルされたモジュール(バイナリパーツ)に
init<_>
関数があることを期待しています。 C / C ++で書かれたモジュールがバイナリモジュールをロードするときに味わうことができるように作られています(そしてPythonにすべてがOKであることを伝えます)。 Vrapper(SWIG)は正直に関数を作成します。
ただし、SWIGはモジュール用に2つの(!)
<_>.py
を作成します。 実際、ネイティブライブラリと同じ
import
ステートメント(アンダースコア「暗黙」)を使用して、バイナリライブラリを「Pythonに」ロードできるということです。 したがって、ネイティブラッパーとバイナリライブラリの名前は異なる必要があります。 それらは異なります-下線。
SWIGは、バイナリライブラリに下線が引かれることを期待しているため、init_ <module_name>と呼ばれる関数を作成しました。 それは間違いです。
2番目のレーキ
コマンドラインオプションをswigコマンドラインコールに渡す方法を理解するために、ソースを登るのに時間がかかりました。 デフォルトでは、
distutil
はCでの作業を想定しています。したがって、
-c++
パラメーターを指定する必要がありました(
-threads
パラメーター
-threads
「ショーオフ用」
-threads
追加されましたが、誰にとっても役に立たない場合があります)。
組立
これでわかったので、モジュールを作成するには2つの方法があります。
MVCを使用してビルドします。
python setup.py build
MinGWを使用してビルドします。
python setup.py build -cmingw32
両方の方法がテストされ、機能します。 さらに奇妙です。
どんなアドバイスも(できるだけ簡単に)歓迎します。 批判もあります(ただし、できれば正確に指示することが望ましい)。 最初のコメントの後で起こったことの半分以上を記事に書き直す必要がないことを願っています。 その後、以前よりも少し深く掘りました。