SConsおよびWafビルドシステムの概要

私は開発者であり、ここ数年、Pythonをメイン言語として使用しています。 ただし、C / C ++で記述する必要があるタスクが時々あります。 そのようなプロジェクトを収集できるさまざまなシステムがあります。 クラシックはmakeとautotoolsです。 SConsやWafなどの代替に焦点を当てたいと思います。 投稿の目的は、makeよりも良いか悪いかを証明することではありません。 私は、それが何であるのか、それがなぜであり、どのようにそれを使い始めるのかをおおよそ明確にするために、短い遠足をしたいだけです。



会話を実質的にするために、実際にシステムを検討することを提案します。 私は、典型的ではあるが常に些細なアセンブリタスクが必要な単純なプロジェクトを使用することにしました。 単純なWebサーバーを作成します。その目的は、別のhtmlファイルに準備された静的ページを作成することですが、最終的には実行可能ファイルに埋め込む必要があります。 つまり、アセンブリ段階で、cコードを含むソースコードをhtmlコードを使用してアセンブルする必要があります。 サーバーライブラリとしてmongooseを使用します。このソースはプロジェクト内に配置され、静的ライブラリに収集されます。静的ライブラリは、後で実行可能ファイルにリンクします。 タスクは明確だと思います。







では、なぜこれら2つのシステムが経験のために選ばれたのでしょうか？ 結局のところ、まだRake 、 CMake 、Ant / NAntなどがあります。 答えは最初の文にあります：それらはPythonに基づいており、私は彼をよく知っていて愛しているので、私にとってエントリーのしきい値はかなり低いはずです。 さあ始めましょう...

準備する

SConsを介してプロジェクトをアセンブルするには、システムにインストールする必要があり、プロジェクトのルートにSConsturctスクリプトが必要です。 少なくともUbuntuでは、SConsパッケージは標準リポジトリに存在し、インストールには問題がありません： `apt-get install scons`。



Wafを介してプロジェクトをビルドするには、Waf自体が必要です。これは単一のファイルとして提供され、プロジェクトのルートに配置されます。 つまり、システムにWafをインストールする必要はなく、コードユーザーはバージョン管理システムから「バッテリー」を含むプロジェクトを取得します。 さらに、wscriptと呼ばれるアセンブリスクリプト自体が必要です。



プロジェクトツリーは次のようになります。



~/devel/stupid-server$ tree

.

|-- external

| `-- mongoose

| |-- mongoose.c

| `-- mongoose.h

|-- html

| `-- index.html

|-- html2c

|-- SConscript

|-- SConstruct

|-- src

| `-- main.cpp

|-- waf

`-- wscript









説明したファイルに加えて、html2cとSConscriptの2つのファイルがあります。 それらについてさらに説明します。

コンパイルとリンク

Scons

とりあえず、html変換を先送りにしてサーバーを構築します。 彼が私たちのmain.cppに組み込まれている答えを与えている間にしましょう。



以下が必要です。システムは、mongooseを静的ライブラリにコンパイルしてから、src / main.cppをコンパイルし、これらすべてを単一の実行可能ファイルにリンクする必要があります。 同時に、すべてのアーティファクトを別のディレクトリに入れておくとよいでしょう。そうすれば、振り返らずに削除できます。



SConsから始めましょう。 このためのSConstructスクリプトは次のようになります。



env = Environment(

CPPPATH = 'external/mongoose',

CFLAGS = '-O2',

)



mongoose = env.StaticLibrary(Glob('external/mongoose/*.c'))

env.Program(Glob('src/*.cpp') + [mongoose], LIBS=['dl', 'pthread'])









ここで、最初の行では、環境-SConsシステムの中心ボルトを定義します。SConsシステムでは、必要なツールを構成します。 今回の場合、includeパスをmongooseに追加し、最適化を使用してアセンブリにフラグを追加します。 次の行では、マングースの構築方法を決定します 。 これは静的ライブラリであり、external / mongooseディレクトリ内のすべての.cファイルがコンパイルされると言います。 私たちの場合、ファイルは1つですが、多数ある場合、Globはそれらをリストする必要をなくします。 最後に、3行目で実行可能ファイルのアセンブル方法を決定します。 srcディレクトリ内のすべての.cppと事前定義されたmongooseで構成されていることに加え、標準のdlおよびpthreadライブラリをリンクする必要があります。



収集方法と決定方法に重点を置いています。 スクリプトで説明されているように、SConsでのアセンブリは行ごとに行われません。 代わりに、システムは宣言を使用してシーケンス自体を決定し、目標間の依存関係と、シャッフルタスクによる複数のスレッドでのアセンブリの高速化の可能性を考慮します。



一般に、両方のシステムの説明では、Pythonを知っていれば、アセンブリスクリプトが記述されているため、すべてが単純になることが示唆されています。 構文的にはPythonであるため、実際にはこれはcになりますが、実際の作業にはこれらのシステムのイデオロギーと作業スキームを明確に理解する必要があります。



SConsに戻ります。 ここで、プロジェクトをビルドするために、ターミナルで「scons」と入力するだけで残ります：Webサーバーが組み立てられます！ ただし、makeの最良の伝統では、アセンブリアーティファクトはソースのすぐ隣に表示され、構造を詰まらせます。 この問題を解決するには、ゴール宣言の転送先となる追加のSConscriptファイルを作成する必要があります。 メインのSConstructから、「このディレクトリでこのSConscriptを収集します」と言う必要があります。 残念ながら、これが唯一の方法ですが、ドキュメントの機能として保護されています。 スクリプトは次のようになります。



# SConstruct



env = Environment(

CPPPATH = 'external/mongoose',

CFLAGS = '-O2',

)



SConscript('SConscript', variant_dir='build-scons', exports=['env'])



# SConscript



Import('env')

mongoose = env.StaticLibrary(Glob('external/mongoose/*.c'))

env.Program(Glob('src/*.cpp') + [mongoose], LIBS=['dl', 'pthread'])









これで、すべてのGibletsが個別のbuild-sconsディレクトリにきちんと折りたたまれます。



これは良い習慣であるため、親ファイルに環境定義を残しました。多くの子スクリプトと共通の環境が存在する可能性があるためです。 ファイル間の転送は、簡単で曲がったメカニズムによって実行されます。それぞれ、exportsパラメーターとImportコンストラクトを使用します。

ワフ

Wafでも同じようになりました：



top = '.'

out = 'build-waf'



def set_options(opt):

opt.tool_options('compiler_cc')

opt.tool_options('compiler_cxx')



def configure(conf):

conf.check_tool('compiler_cc')

conf.check_tool('compiler_cxx')

conf.env.append_unique('CCFLAGS', '-O2')

conf.env.append_unique('CXXFLAGS', '-O2')



def build(bld):

bld(

target = 'mongoose',

features = 'cc cstaticlib',

source = bld.path.ant_glob('external/mongoose/**/*.c'),

export_incdirs = 'external/mongoose',

)



bld(

features = 'cxx cprogram',

source = bld.path.ant_glob('src/**/*.cpp'),

target = 'stupid-server',

lib = ['dl', 'pthread'],

uselib_local = ['mongoose'],

)









最初の2行は、プロジェクトのルートと見なされるものと、アーティファクトを配置する場所を決定します。



ご覧のとおり、これはWafではより論理的です。 以下はset_options関数です。 既存の標準コマンドラインオプションをカスタムオプションで補完するために、Wafによって呼び出されます。 この場合、CおよびC ++コンパイラの動作に影響を与えることができるように、標準のパラメーターセットが追加されます。



以下は設定機能です。 `./waf configure`と言うときに呼び出され、すべての環境変数を設定し、` ./waf build`コマンドでビルドで使用されるすべてのツールを見つけることを目的としています。 2つの段階への分割：構成とアセンブリは、autotoolsで使用されるものと類似しており、高速化に役立ちます。 日常の使用では、構成はほとんど必要なく、アセンブリは永続的です。 これにより、測定可能な時間を節約できます。 私たちの場合、構成では、マシンにCおよびC ++コンパイラがあるかどうかを確認し、それらの場所を覚えてから、設定に最適化フラグを追加します。



次に、特定のビルドコンテキスト（Wafシステムの中心ボルト）をパラメーターとして受け取るビルド関数があります。 このコンテキストは関数として呼び出すことができるため、収集する方法と対象を決定できます。 これを2回呼び出します。mongooseをビルドし、実行可能ファイル自体をビルドします。 各呼び出しで、ソース、ターゲット名、および機能セットが定義されます。 このセットは、ソースを結果に変換するために使用するツールをWafに指示します。 前者の場合、Cコンパイラ（cc）とアーカイバ（cstaticlib）を使用し、後者の場合-c ++-コンパイラ（cxx）とリンカー（cprogram）を使用します。 さらに、実行可能ファイルについては、lib引数を使用して、必要な標準ライブラリを指定します。 また、uselib_local引数を使用して、ローカルマングースへのリンクについて説明しています。



独自のアーティファクトとリンクするために、Wafには、SConsで行われているように、ターゲットリストをソースリストに追加するのではなく、uselib_localのような松葉杖がたくさんあるのは非常に奇妙です。 しかし、そのままあります。 一方、素晴らしい利点は、mongooseへのインクルードパスがmongooseターゲット自体にカプセル化され、トップレベルのどこかで宣言されないことです。 mongooseに依存するターゲットのみが、コンパイラーへのディレクティブとしてこの追加のパスを受け取ります。



さて、このようなスクリプトがあれば、ビルドするには `./waf configure build`を呼び出すだけで十分です。 そして後で、ソースで作業するときに、 `。/ waf build`に制限することができます。

HTMLアセンブリ

htmlからs-codeを取得する一般的に受け入れられている方法がわからないため、そのようなHTMLを作成する小さなhtml2cスクリプトを作成しました。



<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/1999/xhtml">

<html>

<body>

<h1>Hello world from stupid server!</h1>

</body>

</html>









そのような.c：



// Autogenerated by html2c. Think before edit

const char htmlString[] =

"<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.1//EN\" \"http://www.w3.org/1999/xhtml\">\n"

"<html>\n"

" <body>\n"

" <h1>Hello world from stupid server!</h1>\n"

" </body>\n"

"</html>\n"

;









メインファイルからこの行を使用するには、簡単な手法を使用します。



extern "C" const char htmlString[];









プログラミングの観点から見ると、それほどエレガントではありませんが、私たちの目的にとっては最高です。

Scons

SConsが1つのタイプの奇妙なファイルから他のファイルを取得する方法を理解するには、いわゆるBuilderを定義する必要があります。 したがって、環境はStaticLibraryやProgramなどの追加メソッドを取得しますが、これにより問題を解決できます。



# SConstruct

env['BUILDERS']['Html2c'] = Builder(

action = './html2c $SOURCES > $TARGET',

src_suffix = '.html',

suffix = '.c',

)









これで、SConscriptで使用するenv.Html2cができました。



html_c = env.Html2c('html/index.html')

mongoose = env.StaticLibrary(Glob('external/mongoose/*.c'))

env.Program(Glob('src/*.cpp') + [html_c, mongoose], LIBS=['dl', 'pthread'])









このメソッドは、ターゲットオブジェクトの宣言を返し、それを直感的にメインプログラムのソースコードに追加します。

ワフ

まず、構成段階で、html2cユーティリティを見つけて、将来の使用に備えて環境変数にそのパスを保存する必要があります。



def configure(conf):

# ...

conf.find_program('html2c', var='HTML2C', mandatory=True, path_list=[conf.srcdir])









次に、いわゆる新しい変換を定義する必要があります チェーン。Wafに.htmlから.cを取得する方法を指示します。



import TaskGen

TaskGen.declare_chain(name='html2c', rule='${HTML2C} ${SRC} > ${TGT}', ext_in='.html', ext_out='.c', before='cc')









ここでは、以前に構成手順で設定された変数$ {HTML2C}を使用しました。



嬉しいことに、SConsのように、Wafはインポートに魔法を追加しません。 脚がどこから成長するか、この場合はTaskGenモジュールから、常にほぼ明確です。 したがって、必要に応じて、システムのソースコードで関心のある場所をいつでも見つけることができます。



Wafが変換の方法を知ったので、メインプログラムのソースプログラムリストにhtmlを追加するだけです。



def build(bld):

#...



bld(

features = 'cc cxx cprogram',

source = bld.path.ant_glob('src/**/*.cpp') + ' html/index.html',

# ...

)









注意深い読者は、新しい変換では機能に何も追加しなかったことに気付いたかもしれません。 これは、 `TaskGen.declare_chain`メカニズムがWafを拡張するための単純化された、普遍的な高レベルの方法であるという事実によるものです。 これには非常に不利な欠点があります。そのような宣言の後、ソースでwafが見るすべての.htmlは、まず何よりも.cに変換されます。 つまり、別の目標としてftp htmlを何らかのサーバーにアップロードしたい場合でも、システムは親切にそれらを.cに事前変換し、それらをロードします。



機能を考慮した完全なソリューションは驚くほど複雑であり、Wafを深く理解する必要があります。 あなたを眠らせないために、私は彼をここに連れてこないことにしました。

素敵なチップ

両方のシステムには、C / C ++ソース用の組み込み依存関係スキャナーがあります。 つまり、.hファイルの依存関係の宣言を忘れることができます。



どちらのシステムにも統合されたクリーンシステムがあります。 `scons -c`を呼び出すとすべてのアーティファクトが削除され、` ./waf clean`と `./waf distclean`はそれぞれアセンブリアーティファクトと構成キャッシュファイルを削除します。



両方のシステムはクロスプラットフォームです。

SConsはWafよりも優れています

SConsには豊かな歴史があり、コミュニティ内の人々が多く、より多くの出版物で言及され、より多くのプロジェクトで使用されています。



SConsのドキュメントは、Wafのドキュメントより1レベル上です。 どちらのシステムにも電子書籍がありますが、Wafの場合、その内容は20回目から明らかになります。



SConsスクリプトのイデオロギーは、通常、より理解可能で直感的です。 多くの場合、何かがどのように行われているのかよくわからないときは、類推によってそれをやろうとしますが、すべてうまくいきます。 Wafでは、多くのタスクのために、松葉杖を探し、専用のインターフェイスを扱う必要があります。



SConsでは、通常、同じことを1つ、よく、またはいくつかの同様の方法で行うことができます。 曲率に変わることもあるWafの柔軟性により、1000通りの方法で何かを達成できますが、そのうちの1つだけが「正しい」ものであり、他のすべてはさらなるサポートと作業を伴います。

WafはSConsより優れています

Wafは、SConsの起源に立った男性によって比較的最近作成されました。 したがって、SConsの大規模な概念上の障害を考慮して回避しました。これは、大規模で複雑なプロジェクトでは、生産性、保守の容易さ、クロスプラットフォームなどに反映されていました。



WafはSConsよりもはるかに高速です。 私はチェックしませんでしたが、多数の依存関係を持つ数千のソースファイルがあるプロジェクトでは、SConsを10〜15倍上回ると言われています。 個別の構成とアセンブリ、およびよりインテリジェントな低レベルのタスク分散システムのおかげです。 ちなみに、通常のmakeと比較すると、それらは真っ先に行きます：Pythonは遅いですが、サブディレクトリ内のプロセスの再帰的なスポーンのために、makeはその利点を失います。



コンソールへのWafの出力は、SConsよりも比類のないもので、春雨を作ります。 それは色と視覚であり、エラーと警告は非常に見やすいです。



Waf Mobile。 システム全体は、コード内で直接サイズが100 KB未満の1つのファイルに配置されるため、アセンブリマシンに自分でインストールする必要性を忘れることができます。 ほとんどのPosixシステムにあるPythonのみが必要です。



Wafを使用すると、プロジェクトのルートディレクトリ外にあるソースを操作できます。 たとえば、システムにインストールされているがソースコード形式でのみ使用可能なライブラリがある場合。 同様の問題がSConsで発生した場合、窒息しやすくなります。

どちらも良い

両方のシステムのドキュメントは、値札の例ではありません。 両方のシステム用の電子書籍がありますが、SConsだけが通常のリファレンス/マニュアルを持っています。 そして、それは1つの巨大なフットクロスであり、Ctrl + Fでのみ検索できます。 Wafを拡張する場合、複雑なシナリオで、その中に広まっているアスペクト指向プログラミングに関しては、ほぼ確実にソースにアクセスして目的を見つける必要があります。 ドキュメントでは、原則として、このレベルの情報はありません。



そのビルドスクリプトは単なるPython：duckです。 両方の場合。 詳細を考慮して、コードは経験的に実行されるのではなく、1行ずつではなく、システムが決定するランダムな順序で実行されます。 むしろ、コードはもちろん順番に実行されますが、「build_this_thing」が記述されている場合、これはアセンブリが今すぐに実行されることを意味しません。 それはそのようなものがあり、そのようなものがあることを意味するだけで、その場合はそれを集める必要があります。 Pythonの一種のXMLが取得されます。



両方のシステムのソースコードも噴水ではありません。 職場でこのようなものを書いた場合、少なくとも何らかの形で同僚に補償をするために辞めるだけになるように書かれているところもあります。 作成者は理解できますが、ネイティブ環境はC / C ++であり、Python文化の詳細のほとんどを知らない場合があります。

素材

この投稿で解析されたすべてのプロジェクトファイルは、 BitBucketリポジトリで利用できます。