2

共有ワークスペースで使用されるツールを作成します。この分野では複数の OS が動作しているため、通常は Python を使用し、複数のマシンにインストールされるバージョンを標準化しています。ただし、C で何かを書きたい場合は、アプリケーションを Python スクリプトにラップして、オペレーティング システムを検出し、C アプリケーションの正しいバージョンを起動することができないかと考えていました。各プラットフォームには GCC があり、同じシェルを使用します。

1 つのアイデアは、C をユーザーのローカル ~/bin にコンパイルし、タイムスタンプを C コードと比較して実行するたびにコンパイルするのではなく、コードが更新されたときにのみコンパイルすることでした。もう 1 つの方法は、プラットフォームごとにコンパイルして、ラッパー スクリプトに適切な実行可能ファイルを選択させることでした。

これに対して受け入れられた/安定したプロセスはありますか? キャッチはありますか？代替手段はありますか (ネイティブ C コードを使用することが絶対に必要であると仮定して)?

明確化: ABI を共有しない複数の OS が関係しています。例えば。OS X、さまざまな Linux、BSD など。共有フォルダー内のコードを更新し、新しいコードを多かれ少なかれ瞬時に動作させる必要があります。バイナリまたはソース パッケージの配布は理想的とは言えません。

4

4 に答える 4

2

実行する適切なバイナリを選択するためだけに Python インタープリター インスタンスを起動すると、必要以上に重くなります。エイリアスを提供するシェル .rc ファイルを配布します。

/shared/bin には、さまざまなバイナリを配置します: /shared/bin/toolname-mac、/shared/bin/toolname-debian-x86、/shared/bin/toolname-netbsd-dreamcast など。共有シェル .rc ファイルでは、OSX ではエイリアス toolname=/shared/bin/toolname-mac などを取得するように、プラットフォームに応じてエイリアスを設定するロジックを配置します。

ユーザーがエイリアスをリロードする必要があるため、常に新しいツールを追加している場合、これはうまく機能しません。

ただし、この方法でツールを配布することはお勧めしません。ツールの新しいビルドのテストと認定には、ツールをユーザーに配布するために必要な余分な時間は取るに足らないほどの時間と労力が必要です。配信時間を短縮するための最適化を行っているようです。ライブ環境でツールをすばやく置き換えると、ツールの作成と構築で問題が発生した場合、特にクロスプラットフォームの問題が忍び寄った場合に、長く混乱するダウンタイムが発生する可能性が非常に高くなります。

于 2008-09-02T19:29:07.193 に答える
1

また、autoconf を使用して、アプリケーションをソース形式でのみ配布することもできます。:)

于 2008-09-02T16:03:04.117 に答える
0

ご存知のように、静的リンクを検討する必要があります。

最近では、誰もが巨大なハード ドライブを持っており、(libc などを持ち運ぶための) 数メガバイトの余分な容量は、もはや大した問題ではありません。

アプリケーションを chroot() 刑務所で実行して配布することもできます。

于 2008-09-02T15:58:10.633 に答える
0

混合 OS OS によっては、システムのクラスごとにパッケージを作成したほうがよい場合があります。

または、それらがすべて同じ ABI とハードウェア アーキテクチャを共有している場合は、静的バイナリをコンパイルすることもできます。

于 2008-09-02T15:59:52.300 に答える