2009-07-22 1 views
0

私は、いくつかの "生成された"ファイル(foo.yy-> foo.cc)を含むautoconf/automakeを使った、かなり複雑な(C++)プロジェクトを持っています。実際のビルドは、さまざまなプラットフォーム上の "制御スクリプト"(概念に精通している人向けのGentoo。生成されたファイルを配布に追加する最も良い方法は?

ターゲットプラットフォームの1つでは、foo.yy-> foo.ccステップを適切にサポートしていないため、Linuxボックスで生成されたfoo.ccファイルを使用する必要があります。

今、私はこれについて移動する二つの方法があります。

1)foo.yy/fooの上のタイムスタンプチェックを含めるために、プロジェクトのリポジトリと何とかパッチconfigure.in(または何でも)にfoo.ccでチェック.cc、古くなったfoo.ccで問題のターゲット上で実行すると、わかりやすいエラーメッセージが生成されます。

2)foo.ccを制御スクリプトリポジトリにチェックインし、スクリプトでタイムスタンプを制御してエラーメッセージを表示させます。

私は2)問題はありませんが、foo.ccを置くのは適切な場所ではないと思います。

一方、私はautoconf/automakeについてよく知らないし、configure.in(またはwhereever)にタイムスタンプチェック/エラーメッセージを実装する方法も知らないだろう。

あなたの提案は何ですか?解決方法1については、ここでどのように知っていますか?

編集:解決策3)を使用して問題のターゲットボックスを調整し、foo.yy-> foo.ccステップ自体を実行できるようにします。 私の問題が解決しました。

しかし、私は質問を開いたままにしておきます - autoconf/automakeでタイムスタンプチェック/分かりやすいエラーメッセージを出す方法? Automakeにマニュアルで8.8から

答えて

0

‘ YACC ’(又は‘ LEX ’)によって生成された中間ファイルが作られる任意の分布に 含まれます。そうすれば、ユーザは には‘ yacc ’または‘ lex ’が必要です。

これは、説明している問題が存在してはいけないようにしています。

+0

「make dist」を実行してから、* that *をターゲットに配布し、配布からパッケージをビルドします。しかし、この場合は実行されません。バイナリはCVSのものから直接構築されます... 編集した質問を参照してください - 個人的にはもう問題ではありません。 – DevSolar

+0

VCSから直接配布するのはなぜですか? (私は 'CVS'がタイプミスであることを願っています。あなたはまだCVSを使っていませんか?)開発ボックスでautotoolチェーンを実行し、生成されたtarballだけを配布すれば本当に簡単です。特に、yaccやlex、autoconf、automake、libtool、m4などをターゲットボックスにインストールする必要はありません。 –

+0

"make dist'は、automake(またはGNUの規則に従っているパッケージ)を使っているときに配布を作成する方法です。あなたがautomakeが提供するものを使用しない場合、automakeはあなたを助けるために多くをすることができません。 – Braden

関連する問題