web-dev-qa-db-ja.com

クロスプラットフォームライブラリ：プロジェクトを整理する方法？

当社はクロスプラットフォームのC++ライブラリを開発、販売しています。 バイナリのみ Windows、Mac OS X、Linux、iOS、Androidなどのバージョンを配布しています。お客様が入手できる唯一のソースコードは、クラスインターフェイスを持つヘッダーファイルです。私たちのIDEはVisual Studioです。すぐに使用できるクロスコンパイルがサポートされるようになったことを非常に嬉しく思います（Clang！XCodeを搭載したMacのリモートコントロール！古いバージョンのを呼び出す機能コンパイラ！私たちの生活をはるかに簡単にします。同じビルドマシン（Macを呼び出してiOSおよびMac OS Xポートを呼び出す）ですべてのバージョンを同時にビルドしようとします。ほとんどのお客様はWindowsおよび最近のVisual C++のライブラリを入手するだけですが、一部の顧客はその作品を入手しています。

コード自体はプラットフォーム間で同じです。

ただし、すべてのお客様が最新バージョンのVisual Studioを使用しているわけではありません。一部のお客様は2005年までさかのぼってバージョンを使用しています。新しいバージョンへの移行を推奨する一方で、古いバージョンもサポートする必要があります。彼らはバグを見つけた場合のもの。

これにより、製品構成が急増します：​​（デバッグ/リリース）*（静的ライブラリ/共有ライブラリ）*（プラットフォーム）*（x86/x64/ARM）*（コンパイラバージョン）

それらのほとんどは互いに非常に似ていますが、いくつかの違いがあります。

私はMSBuildを勉強していて、.vcxprojファイルですが、それでも非常に複雑に見えます（そして、Visual Studioは.vcxproj最小限の調整以上のものを含む）。

これに対処するために使用した方法は、新しいビルドを行うたびにプロジェクトを手動で微調整することでした。それは明らかに持続不可能です。

私はプロジェクトを最新の状態にするために割り当てられ、最初に、上記の不条理なクロス製品に対応する一連の新しい構成を作成しました。これで40の構成になると思います。ああ。しかし、管理上の問題は別として、（たとえば）x86から​​x64にコピーするときに、必要なプロジェクト設定を常に変更するとは限りませんでした。そのため、バッチビルドを実行したときに、一部の新しい構成がビルドされませんでした。

この問題が再び発生するのを防ぐために、プロジェクトファイルに新しいユーザーマクロをたくさん作成しました（おそらく.propsで参照されるファイル

<ImportGroup Condition="'$(Configuration)|$(Platform)'=='Release-2013|Win32'"
 Label="PropertySheets">
    <Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props"
     Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')"
     Label="LocalAppDataPlatform" />
    <Import Project="$(VCTargetsPath)Microsoft.CPP.UpgradeFromVC60.props" />  
</ImportGroup>

私は推測する）そして、すべてのプロジェクト構成が同じであること、およびそれぞれの間の変更がユーザーマクロで行われたことを確認しました。しかし、それも手に負えなくなっており、ビルドする適切なものを選択するために40項目のメニューをプルダウンし、さらに、適切なフォルダーに移動して関連ファイルを選択する必要があり、エラーも発生しやすいようです。

だから私の質問は、どうすればこれをより自動化して、それほど多くの考慮を必要としないのでしょうか。クロスプラットフォームライブラリを作成している人は、プロジェクト内の40以上の構成で本当に機能しますか？実際の生活でこれをどのように処理するか-または、少なくとも多くの間違いをしないように設定する方法は？

librariesvisual-studioproject-structurecross-platformmsbuild
2
Snowbody

私の過去のプロジェクトでは、あなたと同じように、非常に大量の構成を処理する必要がありました。最後に、私はVisualStudioのIDE構成管理をスクリプト化されたもの（私の場合はPremake）を優先して削除しました。これにより、使用したい構成（または同時に）、スクリプトシステムにさまざまなオプションをクロスコンバインさせるだけで、たとえば、「両方の「デバッグ」について、「VS2013 x64、VS2013 x86、VS2015 x64、およびLinux x64のソリューションを構築する」と伝えることができます。そして「リリース」」。

IDEにすべてを搭載するほどではありませんが、設定を変更する必要があるたびに、狂ってしまうことなく、すべてのオプションを細かく制御できます。

2
Jesus Alonso Abad