私は現在、趣味のプロジェクトとして小さな図書館に取り組んでいます。積極的にコーディングしているのは私だけですが、友人の何人かは将来の参加に興味を示しています。
ライブラリを自分の目的で使用する場合、通常はIDEを使用して適切なソースファイルをプロジェクトに追加するだけです。 (たとえば、.h
および.cpp
ファイルをXcodeにドラッグします。)ただし、ライブラリのサイズと複雑さが増すにつれて、私は組織に対するより専門的なアプローチに移行しようとしています。
将来の参加者がライブラリを「モノリシック」ライブラリファイルにコンパイルするために使用できる、ある種のメイクファイルを設定することを検討しました。私は複数のコンピューターでコーディングしているので、これは私にとっても有益かもしれません。そのようなベンチャーは努力する価値がありますか?
注:Boostライブラリを調べて、それらがどのように機能するかを確認しようとしましたが、これまでの経験がないとナビゲートするのがかなり難しく、構造を理解するのに苦労しました。
はい。
選択したIDEは、コードの存続期間内に変更される可能性があります。特に、コードを離れて、5〜10年後にコードに戻る場合はそうです。
また、コードを共有しているときに、意図せずに環境を押し付けるのではなく、他の人が選択したツールを簡単に使用できるようにすることもできます。
automake / autoconf は、UNIXライクなシステム(OSXを含む)でコードを移植できるようにするので、調査する価値があります。OSXは、本質的にプロプライエタリライブラリ/ファイルシステムレイアウトを備えたBSDです。 おそらく Windows。
友達と共有する前に、コードのライセンスを取得する方法(またはライセンスを取得するかどうか)を必ず検討してください。配布後にライセンスを課すことはできません。これは、プロジェクトを商品化した場合や、他の人の商品化を停止したい場合に関連する可能性があります。それ。
はい、特にそのようなオプションを検討している場合は、そうしてください。
自動展開方法は、常にあなたや他の人の全体的なエクスペリエンスを大幅に向上させます。 MakefileはUNIXおよびUNIXライクなシステムでのみ機能することに注意してください(http://en.wikipedia.org/wiki/Unix-like)。そのため、Windowsユーザーはそれを使用できなくなります。
確かに私の場合、ビルドアウトとMakefileを使用していたので、[Makefile]は長いコマンドまたは一連のコマンドの一種のスマートエイリアスとしてのみ機能するため、Windowsの下のユーザーはビルドアウトに固執し、cmdに長いコマンドを入力しています。しかし、質問に戻りましょう。この場合の自動化は、大多数のデプロイメントサーバーと同僚がLinuxを使用しており、デプロイするたびに時間が半分に短縮され、システムを作成して知っている人にとっては、まだ時間の価値があります。
したがって、私の提案は、どの方法で展開/構成時間を可能な限り短縮するか、そしてそれをどれだけ速くセットアップできるかを検討することです。この場合、ファイルを作成するのは素晴らしいオプションだと思います。自分で手に入れたいものを作ってみてください。私は個人的に、1つのコマンドをインストールして優れたドキュメントを入手したいと思っています。他の人が何か他のものを欲しがるだろうとは思えません。
はい、ビルド自動化ツールは複雑なプロジェクトにとって非常に重要です。
IDEが使用するプロジェクトファイルは、他のビルド自動化ツールで使用できます。これは、多くの状況でうまく機能します。最近、Visual Studioプロジェクトは、スタンドアロンツールMSBuildでコンパイルできます。これは、多くの人に適しています。自動化タスクを構築します。
XCodeを使用していないため、サポートされているかどうかはわかりませんが、少なくとも私にとっては、聖杯は「メタビルドシステム」です。プロジェクトを使用または移植しているプラットフォームに合わせて、Makefile、VSプロジェクトをビルドするアプリケーション。その後、ネイティブの方法を使用してプロジェクトをビルドできます。
したがって、このメタビルドシステムのプロジェクトだけを保持し、実行しているプラットフォームのネイティブメイクファイル(または...)を生成します。
これは、Qtプロジェクトが通常構築される方法です。
以前はNokia(Trolltech)のqmakeを多用していました。 CMake は、私が説明した方法で機能する、より適切に構築されたシステムだと思います。
私は別の答えでautoconfが提案されているのを見ました、まあ、誰かがそれと代替品で実際の経験を持っていて、それが好きだとは思わない。少なくとも私にとっては厄介です。それを避けてください。
ライブラリを使用することは、より完全なソリューションです。つまり、すべてがライブラリ内にあり、宣言に必要なヘッダーファイルを#includeするだけです。覚えておく必要があるのは、プロジェクトのメイクファイルにヘッダーファイルとライブラリのパスを設定し、プログラムをライブラリにリンクするためのリンカーコマンドを含めることだけです。このアプローチでは、ファイルが少なくなるため、プログラムのメイクファイルがよりクリーンに保たれます。最後に、リンカは必要なコードのみを最終的な実行可能ファイルに入れます。一方、ファイルを手動で含める場合は、必要なコードよりもはるかに多くのコードをリンクする可能性があります。 2つのプロジェクト(ライブラリとプログラム)があるのは少し複雑に思えるかもしれませんが、最終的にはそれが報われると思います。
他の人がビルド自動化の部分についてすでに回答しているので、追加したいのですが、ライブラリが大きくなり、コードを共有したい場合は、gitやsvnなどのバージョン管理も確認する必要があります。