問題タブ [makefile]

GNUとMicrosoftの両方のツールチェーンを使用して、すべての主流OS用のドライバー、ライブラリ、コマンドラインツール、GUI、およびOSインストールパッケージを生成する100万行を超えるマルチプラットフォームプロジェクトのビルドシステムの最良の選択は何でしょうか？

私たちのソースコードは主にCで、Python、C＃、GNU makefile、そして少しのC++とbashが含まれています。これは主に1つのリポジトリにありますが、ソースコードをさまざまなサードパーティにプッシュします。サードパーティはすべて、ソースコードコードリポジトリを持っています。ビルドを高速に保つことにも関心があります。これには、プロジェクトの分割が含まれる場合があります。

現在、GNU make、bash、python、およびMicrosoftのDDKBUILDを組み合わせて使用​​しています。主な問題は、makeの上に複雑なスクリプトのセットを維持していて、サードパーティ（できればオープンソース）のツールを使用することを好むことと、cygwinがWindowsで堅牢であることが証明されていないことです（たとえば、フォークが常に可能であるとは限りません） ）、および現在のビルドシステムはツールチェーンをビルドまたはインストールしないため、ツールチェーンのバージョン変更に対して脆弱です。

ワークステーションの速度にもよりますが、私の現在のプロジェクトをコンパイルするには、約 90,000 の loc + 約 100 の DLL を持つ 1 つの exe ファイルに約 30 分以上かかります。

ビルド プロセスは、Powershell スクリプトから devenv を実行するプロセスの 1 つです。これは問題なく非常にうまく機能します。

問題は、それが遅いことです。このビルド プロセスをスピードアップしたいと考えています。

MSBuild (VS-2005 を使用) は 1 つのオプションですが、コマンド ラインで vb コンパイラ/リンカーにアイコンを指定すると、正常にリンクされないというバグがあります。

VB.NET プログラムを「作成」する他のオプションはありますか?

(より高速なワークステーションはオプションではありません。)

主に娯楽として、 というディレクトリに を作成しmakefile、それを実行可能にしました。ファイルの最初の行は次のようになりました。$HOME/binrebuild.mk

次のように入力できます。

これによりmake実行されます。

これ以外に、これを永続的に悪用しない理由は何ですか:

• makefile は 1 つのディレクトリに関連付けられているため、メイン ディレクトリには適切ではありませんbin。

これまでに悪用されたトリックを見た人はいますか?

いくつかのコメントを収集し、もう少し背景情報を提供します。

1. Norman Ramsey は、この手法が Debian で使用されていると報告しています。それは興味深いことです。ありがとうございました。
2. 「make」と入力する方が慣用的であることに同意します。
3. ただし、シナリオ (以前は言及されていません) は、私の $HOME/bin ディレクトリに、ディレクトリ内の 500 以上のコマンドの主要なメンテナンス ツールであるクロスプラットフォームのメインの makefile が既に含まれているというものです。
4. ただし、ある特定のマシン (のみ) で、特別なツール セットを構築するためのメイクファイルを追加したいと考えました。したがって、これらのツールは、rebuild.mkこの質問のために呼び出した特別なメイクファイルを取得します (私のマシンでは別の名前が付けられています)。
5. make -f rebuild.mk代わりに「 」を使用することで、「 」と入力する手間を省くことができますrebuild.mk。
6. ユーティリティの位置を修正することは、makeプラットフォーム間で問題があります。
7. この#!/usr/bin/env make -f手法は機能する可能性がありますが、公式の交戦規則では、行は 32 文字未満で、コマンドの引数は 1 つしか指定できないと考えられます。
8. @dF は、この手法では作成する引数を渡すことができない可能性があるとコメントしています。いずれにせよ、それは私の Solaris マシンでは問題になりません。私がテストした 3 つの異なるバージョンの「make」(Sun、GNU、私のもの) はすべて、オプション (私の自作バージョンでは「-u」) とターゲット「someprogram」およびマクロ CC を含む、私が入力する追加のコマンド ライン引数を取得しました。 ='cc' WFLAGS=-v (別のコンパイラを使用し、Sun コンパイラが認識しない GCC 警告フラグをキャンセルするため)。

これを一般的な手法として推奨するつもりはありません。

述べたように、それは主に私の娯楽のためでした。この特定の仕事のためにそれを保持するかもしれません。分散作業で使用する可能性はほとんどありません。もしそうなら、私は ' fixin' スクリプトを提供して適用し、インタープリターのパス名を修正します。実際、私はすでに自分のマシンでそれを行っていました。そのスクリプトは、Camel ブック (Larry Wall による「Programming Perl」) の初版の遺物です。

linux/freebsd 用に作成する代替手段は何ですか?

Emacs の使い方を少し前から学んでいます。これまでのところ、とても気に入っています。

私の問題は、小さな C コードの場合、Make ではなく Rake を使用することを好むことです。ただし、flymake は Make 以外は何も望んでいないようです。Makefileが見つからないと不平を言うので。コマンド ラインから Rake は Make と同じように使用されるので、flymake で Rake を使用できるようにするために入力できる emacs 構成があるかどうか疑問に思っていましたか?

私がやっていることを少し修正するために。私は実際に Rakefile を編集しているわけではありません。そして、flymake-ruby はまったく役に立ちません。私はCコードを扱っています。RAKE を使用して、MAKE の代わりに gcc を使用して C コードをコンパイルします。

「make」は、プログラミング プロジェクトの構築に役立つだけでなく、他の分野ではあまり使用されていないようです。

たとえば、多くのシェル スクリプトを Makefile として書き直して、独立した部分を (「make -jXX」を使用して) 並行して実行できるようにして、すべての CPU コアをビジー状態に保つことができます。シェル スクリプトで副作用のあるいくつかのタスクの順序を変更することを検討してください。

make / Makefile の珍しい使用法に関する興味深い話はありますか? 安価なジョブ スケジューラとして他のユーティリティを使用していますか?

ワークフロー内の何かが繰り返しタスクであることに気付いたときはいつでも、それを自動化しようとします。

たとえば、サーバーに何かをデプロイするために必要な手順です。多くの場合、ビルドであり、その後にscpが続き、最後にいくつかのリモート セットアップ スクリプトが続きます。

1. mvn パッケージ
2. scp ターゲット/foobar.jar サーバー:
3. ssh サーバーのインストール-foobar
4. ssh サーバー './bin/foobar 再起動'

このような場合、私は次のような小さな Makefile を作成する傾向があります。

ワークフローをどのように自動化しますか?
Ant は最適なツールですか? 長所/短所は何ですか?

安全で無料の Linux 用の、言語にとらわれない優れた分散 make システムはありますか?

背景情報:

私は科学実験 (コンピューター サイエンスの実験) を実行します。この実験では、時には大きな依存関係ツリーがあり、時には数千または数万のツリー ノードが含まれることもあります。この依存関係ツリーは、データ ファイル、データ処理実行可能ファイル、および結果ファイルを対象としています。

私は何年にもわたって、次のようなさまざまな手法を試してきました。

1. データベースを使用して独自の依存関係トラッカーを展開し、各ワーカー マシンでスクリプトを実行します。これは、特に非スクリプト言語で作業しようとすると、少し面倒になる可能性があります。
2. すべての処理コマンドを単一の makefile に入れ、さまざまなワーカー マシンで手動で「構築」できる疑似ターゲットを使用します。これには特別なツールは必要ありませんが、手動で作業を均等なサイズの疑似ターゲット チャンクに分割し、各ワーカー ボックスで「make」を正しく呼び出すのは面倒です。
3. distmake : 単一のメイクファイルからコマンドの実行を自動的に分散します...

私は基本的に distmake のようなものを探していますが、より安全です。私が知る限り、distmake は本質的に、各ワーカー ノードに大きく開いたバックドアを残します。

また、代替品が distmake よりも堅牢であるとよいでしょう。メインの distmake 呼び出しを中断すると、バックドア サーバーをシャットダウンできますが、ワーカー ノードで実行中のプロセスを適切に強制終了することはできません。

説明:

gccでコンパイルしてリンクするのではなく、メイクファイルでデータを処理しています。ドキュメントを読んだところによると、distcc は gcc を配布するための専用ツールです。ソースファイルの gcc ではなく、共有ファイルシステムでホストされている非常に大きなデータファイルで独自の実行可能ファイルを実行するので、distcc は役に立ちません。

ワーカー ノードは外部から見えるマシンなので、すべてのワーカー デーモンを少なくとも ssh と同じくらい安全にする必要があります。ソースを読まなくてもわかることですが、distmake ワーカー デーモンはポートを開き、それに接続するすべてのユーザーからのコマンドを受け入れます。デーモンを起動したユーザーとしてコマンドを実行します。

次のようなプロジェクト ファイルを含むこの小さな Qt プロジェクトがあります。

それからライブラリをコンパイルすると、qmake && nmakeファイルになります

lib と dll の名前に追加の 0 が追加されるのはなぜですか?

生成されたメイクファイルはそれを追加していないように見えますが、単にそれを想定してMakefile.Releaseいるだけです。

どうすればそれを防ぎ、ライブラリに好きな名前を付けることができますか?

(makefile.release を手動で修正することは、受け入れ可能な解決策ではないことに注意してください)