C ++の反射のドロップ。 パート2：GitHubでの公開

この記事は、C ++クラスに関する最小限のメタ情報を追加して使用するように設計されたcpprtライブラリに関するシリーズの第2回です。



最初の記事とは異なり、cpprtライブラリ自体についてはほとんど何もありません。 GitHubで文明化された出版物のライブラリの設計の歴史を説明するために、ライブラリから可能な限り詳細に抽象化することを試みました。



この記事では、ライセンスの問題、プロジェクト構造、およびCMakeに多くの注意が払われています。

0.はじめに

導入的な言葉を言う必要性を遅らせるために、この出版物の構造を紹介します。



セクション番号0 。 このセクション。 出版物の構造と導入語の説明。

セクション1 。 ライセンスについて少し。

セクション2 。 メインプロジェクトのgitリポジトリとは別のサブプロジェクトのgitリポジトリを作成する方法について少し説明します。

セクション3 。 一般的なプロジェクトの構造に関する考えと、いくつかの既存のリポジトリの構造を分析しようとしています。

セクション4 。 cpprtプロジェクトのcmake構成開発記録に基づいたCMakeレッスン。

セクション5 。 ドキュメントに関するいくつかの言葉と多くのリンク。

セクション6 。 図書館の促進に関する考えを記した短いセクション。

セクション7 。 結論とクレジット。



だから 構造があり、まだどこかで開始する必要があります...さて、それをやってみましょう。



記事の目的： GitHubで公開するためにライブラリを準備した方法について説明します。



私は記事に取り組みながら、同時にオープンソフトウェアの世界のいくつかの側面を調査しました。 私の意見では、このため、この記事は旅行の最初の段階にいる人にとって貴重なものになります。素材を探してネットワーク全体を登る必要はありません。リポジトリを収集するために行かなければならなかったサイトへのリンクを最大限に維持しようとしました。



この記事のように、リポジトリが理想とはほど遠いことをよく知っています。 個人で書いて、コメントを書いて、図書館を見て、図書館にコミットしてください-私は記事のクレジットでなされた提案の著者に言及することを忘れないでしょう。 あなたの編集のそれぞれは、あなたの足跡でオープンソースソフトウェアの世界に入る人々を助けます！



たくさんの哀れみを覚えました...さて、今少し歴​​史。 シリーズの最初の記事で、cpprtライブラリクラスとマクロが私の大規模プロジェクトの一部として使用されたことに言及しました。 それらは個別に割り当てられず、単にソースコードの一部として存在していました。 しかし、ある時点で、これらのクラスはメインプロジェクトにほとんど依存せず、その機能は自給自足であり、いくつかの典型的なタスクに適用できることに気付きました。



そして、プロジェクトの一部を別のサブプロジェクトに分け、長年の夢であるオープンソースライブラリを公開することを実現することにしました。



さらに読む前に、おそらく次の考えを読むことに興味があるでしょう（最初の記事を読んでいない場合）：これらの出版物の本当の陰湿な動機の認識（ リンク ）。



そして、読者へのさらに2つの警告：









それでもこの作品を読むことを思いとどまらせることができなかったら、行きましょう！

1.ライセンスの選択

コードの品質に関係なく、私の目にはソースコードがより重くなります。 一部の人にとってはばかげているように思えるかもしれませんが、私にとってはライセンスのある帽子です。 ここに私は見ます：帽子があります-それはプロジェクトが本当に進んでいることを意味します。 帽子はありません-それほどクールではありません。 それは何らかの形で潜在意識に自動的に作用します。



したがって、ライブラリを公開することを決めたとき、最初に触れたのは、ソースにライセンス情報を含めることでした。 そして、このために、ライセンスを選択する必要がありました。



私はライセンスの問題を慎重に研究し始めました。 私はいつもこのトピックを恐れていました。 私は考えました：間違ったライセンスを選択します-そして今、私は投票権を含むいかなる権利も持たずに、私の終わりまで無料でコードをサポートする義務があります。



実際には、すべてがそれほど怖くないことが判明しました-いずれにせよ、オープンソースソフトウェアのライセンスについて話す場合（私はまだ独自のライセンスを見つけていません）。 選択する際に覚えておかなければならない唯一のことは、そのようなライセンスを2つのグループに分けることができるということです： オープンソースとフリーソフトウェア 。 似ているように聞こえますが、オデッサで言うように、2つの大きな違いがあります。 よく見てみましょう：



オープンソース 注意、オープンソースの「オープン」は偶然ではありません！ オープンソースは、それを使用するすべてのコードをオープンソースにします。同時に、オープンソースコードのソースは要求に応じてオープンする必要があります。

たとえば、オープンソースライセンスの下でプロジェクトでライブラリを使用します。 1年を使い、2年を使います...そして突然、 すべてのコードを表示するように求められます。 そして、あなたには拒否する権利はありません！ 強制IT共産主義。 「ソースごとのそれぞれから、ソースごとのそれぞれへ。」 この見込み客があなたを怖がらせている場合-接続しているプロジェクトのライセンスに注意してください。

オープンソースライセンスファミリ内のコードのオープン性を保証する一連のメソッドには、 独自の名前copyleftがあります。 コピーレフトを含むメインライセンスは、GPL （General Public License）とその関連ライセンスです（コピーレフトのGPL 3ライセンスから引用： 「GNU General Public Licenseは、ソフトウェアおよびその他の種類の作品の無料のコピーレフトライセンスです ）） 。



利点：コードの完全なオープン性により、読者の範囲が広がるため品質が向上し、作家の範囲が広くなるため開発が加速されます。 そして、もちろん、もう一つの利点-あなたは世界に良いものをもたらすと感じています。 戦争ではなくオープンソースを作りましょう！

短所：独自のコードおよび/または商用秘密を含むコードでGPLライセンスの下で製品を使用する能力は制限されています。 オンデマンドでそれを伝える必要がある場合、それはどのような秘密ですか？



フリーソフトウェア 。 フリーソフトウェアライセンスにより、ユーザーは制限なしでコードを使用して何でもできます。場合によっては、純粋に条件付きの要件があります（たとえば、元のライブラリの作成者を示す義務があります）。 そのようなライセンスの1つは、たとえばMITライセンスです。 これには、 BSDライセンスファミリも含まれます。

利点：寛大な商業会社からの追加の品質コミット。

短所：貪欲な企業は、コミュニティと共有せずに、コードを自分で盗み、企業リポジトリに分岐し、自分だけのために静かに開発できます。



劣等公的ライセンス 。

オープンソースコードのライセンスには、LGPL （Lesser General Public License）および関連ライセンスが含まれます。 このタイプのライセンスには、オープンソースとフリーソフトウェアの両方の機能が含まれています。

LGPLは、制限なく、コードを開く必要なく、商用プロジェクトを含め、どこでもバイナリ表現（実行可能ファイルまたは動的ライブラリ）にコンパイルされたコードを自由に使用できます。

ただし、LGPLライセンスの下でプロジェクトソースをプロジェクトのコードに静的にリンクする場合は、オープンソースの世界で独自のソースが必要になります。 幸いなことに、ライセンスにはソースコードの公開は必要ありません。 悪い点は、これらのソースが収集されるオブジェクトファイルの公開が必要なため、他の人がそれらを再リンクして、オープンソースのイデオロギーによって指示されたソフトウェアを変更する権利を遵守できることです。

LGPLを使用したプロジェクトの例はQtです。 LGPLライセンスにより、そのダイナミックライブラリは、制限なしに独自のソフトウェアで使用できます（公式Qtフォーラムでのこれの議論とqtcentreウェブサイトでの同様の議論 ）。



利点：商業組織のコードの品質に対する間接的な関心（収集されたライブラリのコードがうまく機能することを望んでいます）と同時に、LGPLプロジェクトの開発の禁止は、無料のソフトウェアライセンスで可能な「サイレント」です。

短所：独自のソフトウェアでLGPLライセンスの下でライブラリを使用するには、dll（または.so）でアセンブルされたライブラリと製品のリンクを整理する必要があります。 LGPLを使用するコードが収集されています。



他の興味深いライセンスについて知っている場合は、コメントでそれらについて書くことができます。 誰にとっても面白いと思います。



既存のライセンスを検討した後、私はMITライセンスを最も自由なライセンスの1つとして選択しました 。 他の利点の中でも、MITライセンスは非常に簡潔です-理解可能であり、派生製品のオープン性に対する権利を保護するための複雑なルールを含める必要はありません。

このセクションの最後にあるこれらのリンクの中には、MITライセンスに関するものがいくつかあります。 そこで彼女は十分によく言われた、私は本質を歪めないために、私は言い直したくない。



セクションの最後で、ライセンス情報をプロジェクトに追加した方法（設計オプションの1つ）について簡単に説明します。



1.リポジトリのルートに、 このサイトからコピーしたライセンステキストを含むlicense.txtファイル（またはLICENCE.txt）を配置します。

2.すべてのソースコードファイルに次のヘッダーを追加しました。







ライセンスについては、gnu.orgを読むこともできます。 彼らはGPLおよび関連するものを使用してソースコードのライセンスを取得する原則について徹底的に話します。 彼らが提供する方法はどのライセンスにも適用できると思います。



約束どおり、興味深い資料への追加リンクのリストでセクションを終了します。

2.メインプロジェクトからコードを切断する

そのため、ライブラリにしたいコードが別のリポジトリに分離されないことがあります。 彼は、メインリポジトリのあるフォルダー内のプロジェクトの作業の最初から生きることができます。これらのソースの編集の履歴は、メインプロジェクトの履歴と密接に関連しており、それを解除する機会はありません。



幸いなことに、すべてはそれほど悲しいことではありません。 このような場合、gitサブツリー分割メカニズムを使用できます。 ここでこのトリックを学びました （まだここで言及されていますが、別の方法であるフィルター分岐についての話です）。 おもしろければ、この石ハンマーを使って私が経験した冒険について、モノリシックリポジトリをサブモジュールに分割し、サブモジュールを使用してそれらからさまざまなものを接着することについて、さらに詳しく説明できます。 ここでは、メインリポジトリの特定のフォルダの編集履歴を別のリポジトリに転送する方法を簡単に説明します。













一般に、それですべてです。 私のメインプロジェクトで説明した手順に従って、将来のcpprtライブラリのソースコードを編集する履歴を分離し、非常に大まかなリポジトリを取得して、ファイルの変更履歴全体を保存します（コミットメッセージにゴミが含まれている場合もあります）。



リポジトリは準備ができていました...しかし、それはまだ公開にはほど遠いものでした。 リポジトリを適切な形式にすることも想定されていました。 このため、ソースコードとライセンスでは不十分でした。テスト、例、組み立て可能なすべてのアセンブリメカニズムの検討、あらゆる種類のread meファイル、ドキュメントなどの作成を支援する材料の束を作成する必要がありました。これらすべてのために、リポジトリの構造を検討する必要があります。この記事の次のセクションでは、プロジェクトの構造について説明します。



便利なリンク：

1. サブモジュールとサブツリーのどちらかを選択して、私が一度尋ねた質問。かなり長い議論と多くのリンクがあります（そのうちのいくつかは既に上で使用しました）。おそらく、プロジェクトのモジュール構成のトピックに興味がある人は、ディスカッションを読んでリンクをたどることが面白いと思うかもしれません。ところで、私はこの機会に、Andy_Uにこの問題について活発に議論してくれたことに感謝したいと思います-最終的にサブモジュールを選択したという事実にもかかわらず。

2. サブツリーを操作しようとしたときに遭遇した困難について説明した別の質問 ...ところで、誰かが私が間違ったことを説明できるかもしれません。

3.リポジトリの構造に関する考察

だから、リポジトリの構造...私の意見では、これはアーキテクチャのカテゴリからのものです。コードのアーキテクチャは、その要素の相互作用の原則を設定します。アーキテクチャ-それは構造でもあります-プロジェクトのリポジトリは、他のプロジェクトとの相互作用の原則を設定します。ここで言う「他のプロジェクト」とは、コードベース、アセンブリシステム、またはビジネスプロセスだけではありません。私はまた、あなたのコードを使用し、それを変更する人々を意味します。



私の理解のために、私はユーザーの観点と貢献者の観点からプロジェクトの要件を策定しようとしました。

ライブラリユーザーの位置からの眺め

ライブラリに精通しているときに、発生順に要件をリストします

。1.自分が何を扱っているかを理解したい。これがプロジェクトのルートにあるものの簡単な説明と、GitHubのプロジェクトページに表示されるように、ある種のReadme。まあ、もちろん、ドキュメント。できれば写真付き。

2.コードの使用方法を確認したい。テスト、コードの使用例、そしてそれがどのように行われるかは明確でした。

3.プロジェクト自体について...アセンブリ、構成、統合に最小限の神経と時間を費やしたいと思います。ヘッダーと、コンパイラーとプラットフォーム用のコンパイル済みライブラリーがあるフォルダーがあれば、それは素晴らしいことです。接続し、本番にリンクします。このビルドシステムを理解したくありません。

注：ここで、さらにC ++に固有のことについて話します。他の言語では、すべてがややシンプルになります...

4.プラットフォームに依存しないプロジェクトがあります！自分でビルドシステムに適応する必要なく、自分でライブラリをビルドできるようにしたいと考えています。言い換えると、CMakeが必要です（CMakeが明確でない場合は、大丈夫です。後で説明します）。

追加要件：

5.したがって、ライブラリには可能性が多すぎます。配送中のツールはありますか？そして、すぐに収集することをお勧めします。

6.私はあなたのプロジェクトを長い間使用しています。彼が最近更新したと聞きましたか？何が変わったのか知りたい。



提示された要件を考慮して、以下の構造が得られます：







1.どんな種類の図書館ですか？

README.txt-プロジェクトの簡単な説明。

/ doc-プロジェクトとそのAPIを詳細に説明するファイルです。



2.テストと例。

/ tests-できるだけ簡単に実行できるプロジェクトをテストします。

/ examples-できるだけシンプルに実行する必要があるサンプル。



3.すぐに接続します...

/ include-アセンブルされたライブラリのAPIにアクセスするためのインターフェイス。

/ lib-ソースの静的ライブラリへのアセンブリ。

/ bin-動的ライブラリへのソースのアセンブリ。

注： libおよびbinフォルダーには、できればメインのコンパイラーとプラットフォームのアセンブリーを含める必要があります。



4.自分で組み立てたい！

/ src-プロジェクトのソースコード。

cmake_readme.txt -cmakeファイルを使用してプロジェクト構成を生成する方法に関するオプション情報。

CMakeLists.txt-アセンブリ構成のファイル。



5.ツール？ここに行きましょう：

/ tools-ライブラリでの作業を簡単にするツール。収集されるか、ソースコードの形式で。



6.

change_list.txt-プロジェクトの最新の変更に関する情報を更新します。

図書館寄稿者の視点からの外観

ライブラリを知るときの要件は、出現順にリストされています：

0。ライブラリを知る最初の段階では、私は寄稿者ではなく、ユーザーです。したがって、最低限、私の要件には上記のユーザー要件が含まれます。

1.私はあなたのプロジェクトが好きで、それを開発したいと思います。友好的な貢献者の家族に参加する方法について、何らかの種類のReadmeを読みたいと思います。

2.ライブラリが内部にどのように配置されているかを理解したい。開発者向けの詳細なドキュメントが必要です。理想的には、プロジェクトのビルドシステムにもドキュメントが必要です。

3.ビルドシステムで作業するとき、プロジェクト全体を登りたくありません。アセンブリに豊富な構成ファイルまたは追加プログラムが必要な場合は、別のフォルダーに入れてください...一般に、すべてが適切である必要があり、ファイルは目的別にグループ化する必要があります。

その他の要件：

4.カスタムツールはもちろん優れています...しかし、プロジェクトは本当に大きなものです。開発者向けのツールが必要です。



全体として、要件を考慮して、理想的なプロジェクトの構造について以下の明確化が得られます



。1.導入情報：

contributors_README.txt-開発に投資したい人のためのプロジェクトの簡単な説明。



2.ドキュメント：

/ doc-

/ developer_doc-プロジェクトの詳細を含むドキュメント。

注：この構造では、ユーザードキュメントもdocフォルダー内の別のフォルダー（一部のuser_doc）に保存する必要があります。私の意見では、このようなドキュメンテーションの構造は、構造的な順序に加えて、ドックを持っている好奇心の強い読者に興味をそそります。「入門者のためのドックの中には何がありますか？」-そして、読者をおそらく貢献者にします。



3.プロジェクト内の順序：

/ build

ビルドシステムのあるフォルダー。プロジェクトのこのフォルダの外に、最小限のビルドシステムファイルをハングアップすることをお勧めします。



4.開発

ツール ：/ tools-

/ developer_tools

ドキュメントと同様に、目的に合わせてツールを収集します：ユーザー固有、開発者固有。



ここにリストされている要件は、私の知覚にとって主観的なものです。それについて何か考えがあれば、それを共有してください。



GitHubを使用してプロジェクトを分析しているときに、CMakeユーティリティを操作するためのファイルについて頻繁に言及していることに気付きました。さらに、いくつかの資料から判断すると、C ++でのオープンプラットフォームのクロスプラットフォームソフトウェアリポジトリの古典的な構造の形成に影響を与えたのはCMakeでした。彼は逃げられないという気持ちが醸成されていました。来る...

4. CMakeへの道

謝辞： CMakeを勉強するきっかけとなったスタニスラフ・マカロフ（Nipheris）に感謝します。



CMakeは、特定のメイクシステム（および/または一部のIDEのプロジェクト）の構成ファイルを生成して、ユニバーサルな抽象的な構成（サポートされているビルドシステム/ IDEのリスト）に基づいてC / C ++プロジェクトを構築できるユーティリティです。生成後、CMakeの終了時に取得された構成および/またはプロジェクトファイルは、特定のビルドメカニズムによって既に使用されています。彼らの仕事の結果としてのみ、組み立てられた製品が得られます。

CMakeはメタメイクツールであり、C / C ++プロジェクトのアセンブリシステムを抽象化したものであると言えます。



私はcpprtライブラリのリポジトリ構造を構築するとき、CMakeの使用をあらゆる方法で回避したことを認めます。典型的な先延ばし...さまざまな言い訳を思いつき、Python、ボディーシャツ、そして私が知っているイチジクでビルドシステムを構成し、サブモジュールにいくつかの壊れやすいデザインを付けました。このすべての狂気の神格化は、CMakeの私の拒絶を正当化する理論全体でした。同様に、cpprtライブラリは非常に小さいため（2つのファイルのみ）、その統合のために、「ライブラリ」のソースコードをサブモジュールとしてユーザープロジェクトに直接挿入するだけで十分です。また、サンプルとツールのソースコードもサブモジュールで配布する必要があります。これにより、ユーザーは必要に応じてライブラリのカブにそれらを取り込むことができます。

さらに、例とツールはcpprtライブラリに依存するため、ライブラリ自体も（注意！）これらのサブリポジトリにサブモジュールとしてビルドする必要があります。結局、例はライブラリをプロジェクトに埋め込む方法を示しているはずです。



したがって、この異端の理論に基づいて、Frankensteinのモンスターのようなリポジトリを、gitメカニズムで接続されたいくつかのミニリポジトリから縫い付けました。それは本当のゴミでした（ここで賞賛できます）。言い訳を拒否する場合は、CMakeを教えるだけではなく、これだけを行いました。



しかし、良心はテレビではありません。彼女の音を消すことはできません。無料の検索の過程でランダムな資料に出くわし、次第に気づきました。CMakeは、C ++向けのオープンソースクロスプラットフォームソフトウェアの現代世界の柱の1つです。CMakeを使用せずにこのようなプロジェクトを行うことは、まったくナンセンスです。これは完全に間違っています。記事でそのような決定について人々に伝えることは、とりわけ、人々に悪いことを教えることを意味します。



したがって、4月12日火曜日、私は座ってCMakeを勉強しました。翌日の夕方までに、私はすでにプロジェクトのCMake構成が機能していて、自分の不安に笑いました。思ったより簡単で、とても便利でした。



以下は、CMakeに没頭したことの記録です。これが誰かを助けることを願っています。







以下に示すすべてのイベントは、実際には2016年4月12日火曜日に行われました。 ブラウザのページ要求履歴によって復元されました。

（0:35）材料の初期検索

CMake（ ここから ）をダウンロードしてインストールした後、レッスンを探し始めました。



" cmakeチュートリアル "の要求で、最初のリンクは公式のドックにつながりました。 基本的に、私はそれを理解しました。 cpprtはまだ非常に小さなプロジェクトであるため、ドックの最初の5つのステップを十分に理解して、ライブラリを構築するための考えられるすべての目標（構築ツールと例を含む）の構成を説明しました。



Googleの最初のページにある「 CMake habrahabr 」のリクエストに応じて、教育的なものとして考案された3つの記事がありました。 私はこの記事が一番好きでした（ちなみに、「cmake tutorial」のリクエストで2番目に脱落しています）。 いくつかの点でドックの翻訳に似ているいくつかの点での良いチュートリアル記事-しかし、より簡潔。 セクションに分かれており、各セクションでCMakeの機能について説明し、不要な殻を使わずに簡単な例を示します。 この記事を追加のトレーニング資料として使用しました。

（2:00）最初のCMake構成を構築します

CMakeで、午前2時に戻りました。 私は簡単にレッスンに精通し、可能な限り単純なプロジェクトで、いくつかのテストで練習することにしました。 次の内容のフォルダーを作成しました（ {cmake_test}という名前にします ）。



main.cpp

構成を生成するアセンブリのテストファイル。





CMakeLists.txt

ソースアセンブリ構成main.cppの説明を含むファイル。 ここで、さらに新しい各CMakeチームに詳細なコメントをします。





これらすべてのテストファイルを作成した後、コンソールを開いて次のことを行いました。



cd {cmake_test}

mkdirビルド

cdビルド

テストアセンブリのあるフォルダーに移動しました。

その中にフォルダーを作成し、そこにCMakeコマンドを使用して構成ファイルを生成します。

作成されたフォルダに移動しました。



cmake -G "MinGW Makefiles" ../

MinGWツールチェーンを介してアセンブリ構成ファイルを生成するための呼び出し。

-G "MinGW Makefiles" -構成ファイルを作成するためのジェネレーターの選択。 Generator-抽象CMake構成から特定のツールチェーン（またはIDE）の構成ファイルを生成するプログラム。

この場合、MinGWツールチェーンに付属しているMinGW32-makeツールのメイクファイルを取得したかったのです。

../-CMakeLists.txtが配置されているフォルダーへのパスと、構成の説明。

説明したコマンドを呼び出した後、プロジェクトをビルドするための構成ファイルが、呼び出し元のフォルダーに表示されます。 この場合、ソースmain.cppからの1つの実行可能ファイルのアセンブリ構成が予期されていました。







この呼び出しは午前2時25分に行いました。 時間は、リクエストの履歴に基づいて、つまり、次の問題に対する最初のリクエストの時間に基づいて復元されます。

（2:25）問題

何も集まりませんでした。 CMakeは次のエラーを生成しました（エラーに関連するメッセージの部分のみを残し、パスを非表示にします）。



{my cmake_path} /share/cmake-2.8/Modules/CMakeMinGWFindMake.cmake:20（MESSAGE）でのCMakeエラー：sh.exeがPATHで見つかりました：ここで{some path}

PATHにsh.exeがないシェルからcmakeを実行します。





私はそれについてグーグルで調べて、 そのような情報を見つけました。 簡単に言うと、sh.exeがシステムパスで使用可能な場合、MinGWのジェネレーターは機能しません。 理由-まだ最後まで理解できず、夜の3時半には特に整理したくありませんでした。特に、私の場合、この問題は簡単に解決できることを考慮してください。



sh.exeが追加されたシステムパス（私の場合はgit）を一時的に削除し、CMakeを再度起動しましたが、...エラーが再度表示されましたが、別のエラーが発生しました。 新しいエラーはもっと気のめいるように見えました（エラーに関するメッセージの部分のみを残します）。



Cオブジェクトの作成CMakeFiles / cmTC_ebbab.dir / testCCompiler.c.obj

C：\ MinGW \ bin \ gcc.exe -o CMakeFiles \ cmTC_ebbab.dir \ testCCompiler.c.obj -c C：\ Users \ test \ Desktop \ ‚јї \ cpprt_FINAL \ current \ github \ build \ CMakeFiles \ CMakeTmp \ testCCompiler.c

gcc.exe：エラー：C：\ Users \ test \ Desktop \ ‚јї \ cpprt_FINAL \ current \ github \ build \ CMakeFiles \ CMakeTmp \ testCCompiler.c：そのようなファイルまたはディレクトリはありません



さまざまなソースを再度読んだ後、このエラー自体が次の理由で発生したことに気付きました。 特定のツールチェーンの構成ファイルを生成する前に、CMakeはこのツールチェーンのコンポーネント（コンパイラ、リンカなど）の存在をチェックし、これらのコンポーネントが正しく機能するかどうかもチェックします。 これを行うには、一時フォルダーにソースコードtestCCompiler.cを作成し、コンパイラーを使用してビルドしようとします。 私の場合、何らかの理由でCMakeはそのようなファイルを作成しませんでした。

残念ながら、これについて具体的なリンクを述べることはできません。このメカニズムのいくつかのエコーを以下に示します。



一般に、エラー自体はもちろん、上記の理由で発生しました。 しかし、これが原因ではなく結果であることは明らかでした。 理由を見つけるために、私は4泊目の始まりの前に、約40分間グーグルで検索しました。 それは「農民」の精神における典型的な二日酔いでした。 このクソコードを機能させ、最後に、そして眠りにつくことは...私を打ち負かしました。 最初にfirstめました。 これは私が夜に3時半まで掘り下げた最も賢明なリンクの1つです。



解決策 ：問題は何でしたか。すでにこの記事を書いている最中でした。 実際には、アセンブリが実行されたフォルダへのパスにはロシア語の文字が含まれていました。 MinGWのmakefileのアセンブリが成功したため、同様の欠陥のないパスにフォルダーにアセンブルする価値がありました。

結論： Unicodeパスに注意してください！ 何かが機能せず、理由がわからない場合は、パスでユニコードを探し、ユニコードなしでパスを作成してみてください！

（10:38）Visual Studio向けのビルド

私は、MinGWのアセンブリとはもうやりたくないという自信を持って目を覚ました。 Visual Studioをインストールしていたので、最初に構成を収集して（または、スタジオの場合はソリューションとプロジェクトを収集して）、他のツールチェーンの構成の生成をテストしてみてください。



コンソールを開き、{cmake_test} / buildフォルダーに移動してCMakeを呼び出し、別のジェネレーターを指定しました。



cmake -G "Visual Studio 14 2015" ../



奇跡！ ビルドフォルダーでは、test_project.slnソリューション、いくつかのプロジェクト（ここで少し驚いた-なぜいくつか）、および構成変更の場合にCMakeがソリューションとプロジェクト設定を更新できることを理解するために必要な補助ファイルの束が形成されました。毎回設定を再生成する必要があります。



ソリューションを開きました。 はい、そうは思いませんでした。 main.cppを実行可能ファイルにアセンブルするための予想されるtest_executable.vcxprojプロジェクトに加えて、他の2つの左利きのプロジェクトALL_BUILD.vcxprojおよびZERO_CHECK.vcxprojがソリューションに含まれていました。 私はグーグルで調べました。 スタックオーバーフローに関するこの回答を見つけました。 それから、これらは、CMakeLists.txtファイルが変更された場合、CMakeが各ビルドの前にプロジェクトファイルを更新するまさにそのプロジェクトであり、これらのプロジェクトファイルの生成元であることに気付きました。 一般に、すべてが正しいので、作成されているはずです。







Visual Studioでは、test_executableプロジェクトをスタートアッププロジェクトとして選択し、ctrl + f5を押しました。 コンソールに「Hello from CMake！」と印刷されました。 うらしっきー乾杯！











作業開始から約1時間が経過しました。

（11:24）CMakeを介したアセンブリのためのリポジトリの準備

これで、CMakeをメインプロジェクトに接続できます。 CMakeの前は、すでに述べたように、私のプロジェクトにはサブモジュールに関する内部組織がありました。 CMakeのおかげで開かれた見通しを考慮して、サブモジュールの使用は放棄される可能性があります。 リポジトリのクローンを別に作成し、すべてのサブモジュールのソースコードを取得し、CMakeを使用してアセンブリを構成する方法について考え始めました。



リポジトリをわずかに再構築したため、見た「アダルト」リポジトリのように人間に見えました。 以下は、CMakeの操作に直接関係するプロジェクト構造の一部です。



/ build-ソースコードを収集することになっている空のフォルダー。

/ include-ライブラリAPIにアクセスするためのヘッダーを含むフォルダー。

/ src-ライブラリのソースコードを含むフォルダー。

/ examples-さまざまなサンプルのソースコードを含むフォルダー。

-/ __ example_hierarchies__-テストクラス階層を含むフォルダー（以下を参照）。

-/ simple_examples-小さなテストケースのソースフォルダー。

/ tools-プロジェクトを操作するためのツールのあるフォルダー。

-/ console-現時点ではツールは1つだけで、その名前はconsoleです。

CMakeLists.txt-プロジェクトのさまざまな要素を収集できるCMakeファイル。



現在のライブラリリポジトリ

この記事に記載されていることは、 e9c34bbコミットにも当てはまります。







ライブラリの配信の一環として、次のピースを組み立てることができると判断しました。







ライブラリの黒色 。

実行可能ファイルの青色 。

アセンブリターゲット間で共有されるソースコードを含むフォルダーの緑色 。



図書館

1. cpprt-実際には、ライブラリ自体。 / srcフォルダーにあるソースコードと/ includeフォルダーにあるインターフェイスから収集されます。

静的ライブラリにアセンブルされ、依存関係はありません。

一例

2. simple_examplesは、OOPに慣れるための動物クラスの古典的な階層を記述し、この階層に基づいてライブラリAPIを使用する単一のファイルで構成される小さな例です。

cpprtライブラリに応じて、実行可能ファイルにアセンブルされます。

計器

3. コンソール -現時点では、これは実際にはライブラリの機能を実証する例でもありますが、独立したツールに変える計画です。

コンソールから、登録済みクラスの継承ツリーに関する情報を表示したり、オブジェクトとクラスの両方の文字列名を使用してクラスオブジェクトを作成および削除したりできます。

実行可能ファイルにアセンブルされます。これは、cpprtライブラリとクラスのテスト階層に依存します。この例では、コンソールを見ることができます。



構造の準備ができました。 CMakeを使用してこれらのアーティファクトを組み立てるための構成を説明する「何もありません」がありました。

（11:30）cpprtライブラリの構築

cpprtライブラリには2つのファイルしか含まれていなかったという事実にもかかわらず、私は将来の作業に取り組み、フォルダーに含まれるすべてのファイルを再帰的に接続する方法をすぐに学ぶことにしました（さらに多くのソースパスはリストしません）。 私はそれをグーグルで検索し、GLOB_RECURSE引数を指定したfileコマンドの使用を説明するこのリンクを見つけました。



小さなProject-OSRMプロジェクトの CMake構成を 簡単に見て、見つかった情報を使用して次の構成コードを作成しました。









ファイルの準備が整ったら、/ buildフォルダーに移動して構成ファイルを収集しました。cmake-G



“ Visual Studio 14 2015” ../



すべてがすぐに統合されました。cpprt.vcxprojプロジェクトで解決策がありました。ソリューションを開き、スタジオを介してアセンブリを開始しました...はい。ライブラリは問題なく組み立てられました。



これは12:41に発生したもので、Facebookリンクを開いた時間に基づいて説明できます。

Facebookの後、一時的に他のタスクに切り替えました。

（16:09）simple_examplesサンプルのアセンブル

2時間半後にcmakeの構成に戻りました。ここで、ライブラリのサンプルを作成するために、構成の生成を可能にする必要がありました。これを行うには、プロジェクト間の依存関係の整理に対処する必要がありました-結局、simple_examplesプロジェクトはcpprtライブラリに静的にリンクされました：







静的ライブラリをリンクするコマンドは、ハーバーのCMakeレッスンで言及されました（2番目の例）。これらのレッスンと他のいくつかのソースを読んだ後、次の構成コードを作成しました。







CMakeの設定からスタジオソリューションを生成しようとしました。まず、サンプルをビルドするオプションを渡し、次にそれを使用しません。たとえば、スタジオ用のソリューションをサンプルプロジェクトとともに生成したコマンドは次の



とおり



です。プロジェクト用にコンパイルされた実行可能ファイルがないこと。間違いはありませんでした。



幸いなことに、すべてが非常に簡単でした-サンプルプロジェクトをスタートアッププロジェクトとして設定するのを忘れました（アセンブリ後、CMakeはデフォルトでBUILD_ALLを設定し、その中に実行可能ファイルは収集されません）。すべてを設定した後、テスト用であるはずのすべてが画面に印刷されました。



これは、17：14までに履歴から回復できたために発生しました-FastDelegateプロジェクトをどれだけ開いたかで判断します（これは、コールバックをプラスで処理するための優れたマイクロライブラリです）。私はそれを私のメインプロジェクトに使用し、そこでビルドシステムがどのように作られたかを見たいと思いました。それは何もないことが判明した...しかし、それは可能であり、正しい。

（17:14）コンソールサンプルツールのアセンブル

コンソールを組み立てるために残った。原則として、このアセンブリに必要なすべてのコマンドを既に知っていました。プロジェクト構造を思い出してください：







コンソールはテストクラス階層でアセンブルできます。ここで、「クラス階層を使用する」という概念は、コンソールの組み立て元のソースのリストにrepository / examples / __ example_hierarchies__のソースを含めることを意味します（ヘッダー検索パスとしてではなく、単に別のソースソースとして）。



コンソールアセンブリの説明を含む構成。コードを詰まらせないように例を構築するために、上記の構成なしで構成を使用します。







コンソールはすぐに集まって獲得しました。すべて準備が整いました。



その時までに（19:23）-私はグーグルで「ミントティーがなだめる」と判断した。



すべての作業の結果：現在プロジェクトで使用されているような構成：







したがって、CMakeユーティリティを使用して、基本的なレベルの実用的なレベルの純粋な時間を4時間で簡単に、そして何もせずに見つけました。私の意見では、CMakeの強力な知識を身に付けることは4時間の価値があります。



結論として、CMake：



私が気に入ったもの：

強力なユーティリティについてお話します。それは、多くのプラットフォームとコンパイラーのための構成で蒸気を発する必要を本当に取り除きます。スタジオの後に、CMakeでmingw32-make + Eclipse IDEのメイクファイルを生成し、以前のVisual Studioで行ったのと同じくらい簡単にソースを組み立てたときに、これを感じました。

気に入らなかった点：

非常に奇妙な言語設計。区切り文字として空白を使用した引数、名前付き引数を使用する奇妙な原理、プロジェクトプロパティとアセンブリ目標を設定するための透過的なメカニズムではない（プロパティはすべてのアセンブリ目標に対してグローバルに設定される場合がありますが、特定の目標に対してローカルに設定されることもあります）実際、すべての操作をファイルシステムと組み合わせ、特定の操作はコマンド引数を使用して送信されます）。



ある瞬間、エイリアンはCMakeの言語を書いたように思えました。とても賢いですが、少し違った考え方をしています。

5.ドキュメントについて

すぐに言わなければならない-私はcpprtライブラリの英語のドキュメントを編集する勇気を持っていませんでした。現在、すべてのドキュメントは、この一連の記事を読むだけで送信されます。これは、おそらくドキュメントがないことを意味します。4週間のマラソンの後、一息ついたらすぐにこの欠陥を修正しようとします。その結果、このシリーズの記事が執筆されました。



実際にはドキュメントを作成しなかったという事実にもかかわらず、ドキュメントを作成するための最良の基礎となるものについて理論的な研究を行いました。ここで見つけた情報を提供します。情報は主にこの記事とそのコメントから取得されました。



















おそらくご存知のように、このようなオープンソースドキュメントのトピックへの最初の紹介の後、Doxygenはこれまでのところお気に入りであることが判明しました。これはおそらく、私がコードを書くのが好きで、あらゆる種類の退屈なドキュメントに目を通すことを好まないプログラマーであるという事実によるものです。



それにもかかわらず、私にとっては、良いドキュメントはDoxygenだけではできません。これは、APIに精通し、場合によってはいくつかの簡単な図を表示するための優れたソリューションです。しかし、多くの場合、UMLのほかに大きくて複雑な画像やイラストを使用して、コードの動作を詳しく説明するより詳細な記事が必要です。とにかく、あなたは自分でやらなければならないでしょう、ペン、ソースコードに関するコメントだけではうまくいきません。



ドキュメントについてはこれ以上言うことはありません。書き込み-補足。

6.図書館振興について

ここでは、この一連の記事を除いて、まだ経験がありません。これは、ライブラリを促進するための実験的な試みです。あなたの経験について人々に話してください。このアプローチがどれほど優れているか見てみましょう。



この出版物および図書館自体に対する読者の肯定的な反応がある場合、このシリーズの記事を英語を話す聴衆に合わせて、どこかに公開しようとします（redditがあることは知っています...誰かが良いリソースを知っているかもしれません）？そして、我々は表示されます...



プロモーションについては、今のところ、おそらく、私はそれ以上言うことはありません。

7.結論

私の研究、過ち、そして最も重要なこととして、他の人々の素晴らしいコメントと彼らのおかげでなされた変更が、読者の皆さん、私よりも早くこの道を進むことを願っています。







, .