複数のビルドターゲットのファイルシステムレイアウト
いくつかのパラメータを使用してソフトウェアを構築およびインストールする方法について、いくつかのアイデアを探しています。これらには、ターゲットOS、ターゲットプラットフォームのCPUの詳細、デバッグバリアントなどが含まれます。ドキュメントや多くのプラットフォームに依存しないファイルなど、インストールの一部は共有されますが、64ビットライブラリや32ビットライブラリなどは共有されません。マルチアーチライブラリで。
大規模なネットワークプラットフォームでは、多くの場合、複数のコンピューターが大きなサーバースペースを共有しているため、実際には、同じディスク上にWindowsとUnixのバイナリが存在する原因があります。
私の製品は、複数のバージョンが共存できるように、$ INSTALL_ROOT/genericname/version /のインストール哲学をすでに修正しています。
問題は、他のすべてのもののレイアウトをどのように管理するかということです。
パッケージがシステムにインストールされている場合、手元にあるシステムは1つだけです。つまり、OS、CPU/Arch、32/64ビット変数はthatシステムターゲット用に固定されています。
このコンテキストでは、通常、私は[〜＃〜] not [〜＃〜]のような別のフォルダを作成します
$INSTALL_ROOT/package//<64-32bit>/versions/
むしろ、私はそれをネーミングの一部として定義します。たとえば、RPMファイルの命名規則を見てください。
name-version-release.architecture.rpm
Fc8やfc11などの配布バージョン番号が含まれています。
Debianも同様の命名規則に従いますが、おそらくパッケージには内部ディレクトリレイアウトがあります。 （申し訳ありませんが、ここに詳細はありません！）
かつて、私はビルドグループのSANメーカーで働いていました。約40の異なるオペレーティングシステムをサポートする必要がありました。
ディストリビューションは、HPUX、Z/OS、Windowsなどのディストリビューションメディア（CDおよびDVD）のルートレベルにある主要なOSファミリによって編成され、バージョンはそれらから分岐しています。したがって、たとえば、WindowsブランチにはそのフォルダからServerとWorkstationがあり、それぞれにx86、x64、ia64のセットがあります。およびAlphaフォルダー、それぞれに独自のインストールがあります。
異なるソースディレクトリとターゲットディレクトリを許可するビルドツールを使用します。プラットフォームごとに、プラットフォーム固有のファイルが生成される個別のターゲットディレクトリがあります。
プラットフォーム固有ではないファイルに共通のビルドディレクトリを使用すると、ビルドの実行速度が上がる可能性があります。