問題タブ [autotools]

ビルド ファイルの単体テストに最適なポリシーは何ですか?

質問する理由は、私の会社が信頼性の高い組み込みデバイスを製造しているからです。ソフトウェア パッチは、お客様が配布するのに何千ドルもかかるため、オプションではありません。このため、非常に厳格なコード品質手順 (単体テスト、コード レビュー、トレーサビリティなど) を採用しています。これらの手順はビルド ファイルに適用されています (知っておく必要がある場合は autotools です。残念です) が、ハックのように感じます。

ええと...プロジェクトがコンパイルされます...ビルドファイルをレビュー済みおよびユニットテスト済みとしてマークします。

もっと良い方法があるはずです。アイデア？

2 つの autotools プロジェクトがあるとします。

• libmyutils
• libmypackage

libmypackage ライブラリは、libmyutils に依存しています。libmyutils パッケージを実際にインストールせずに libmypackage にリンクして参照する方法はありますか? それとも、libmypackage がアクセスできるようにするために、実際に libmyutils をインストールする必要がありますか?

例：

問題は、libmyutils を独自のパッケージとして保持して、他のライブラリ (libmypackage2、libmypackage3 など) が使用できるようにしたいことですが、libmyutils と libmypackage の両方で積極的に開発を行っている可能性があるため、避けたいと考えています。変更を加えるたびに libmyutils をコンパイルしてインストールする必要があります。

これは可能ですか？

私の主な質問は、autotools が INSTALL、COPYING、missing、install-sh、および depcomp へのリンクを作成したことです。それらを表示しようとすると、リンクとしてアップロードされていることがわかったので、実際のファイルに置き換えて表示できるようにしました。基本的な何かが欠けていますか？「make dist」から gz ファイルを解凍すると、次のようになります。

配布ツリー (マイナス ソース ディレクトリ)

README_developers を削除し、README に 2 つのセクションを作成する予定です。また、run.sh と profile.sh を削除して、make テスト ターゲットの一部にすることも検討しています (いくつかの読み取りが必要です)。TODO アイテムがソース ディストリビューションに属しているとは思いませんが、プロジェクトのソース ツリーに含まれていても問題ないかもしれません。リンクの質問を超えた追加のポインターは大歓迎です。

SCM がファイルのタイムスタンプを厳密に記憶していないため、生成された Makefile は、「autoreconf -i」または同等のものを再実行して、Makefile.am から Makefile.in を再生成したり、configure.ac から構成したりする必要があると判断することがあります。 ..

これを防ぐにはどうすればよいですか？

次のような問題が発生するため、防止したいと考えています。

• dist アーカイブ (git archive --format=tar ...) を作成すると、タイムスタンプが不正確になり、エンドユーザーに問題が発生します。クールではありません。
• 低速のシステムでは、これによりコンパイルにかなりの時間がかかります。これは、configure、make、make install ではなく、configure、autoreconf -i、configure、make make install になるためです。

dist tarball を作成する前に、生成されたファイルに「触れる」ことができることはわかっていますが、私の意見では、開発者ではなく、tarball の問題のみが解決されます。また、オフにできるはずの誤機能を回避するのも醜いハックです。また、タイムスタンプが常に正しいとは限らないため、gitアーカイブが破損します。

他の SCM にもこれがあるため、問題は (IMO) git ではありません。

Cygwin で fish を正しくコンパイルできた人はいますか? configure.ac の変更に関するこの投稿を見つけましたが、あらゆる種類のエラーが発生しています。通常のconfigure、make、make installが機能しません。おそらく、ここで何か間違ったことをしているのでしょう...コンパイルする方法を教えてもらえますか?

過去数日間、私は、過去数か月にわたってつなぎ合わせた Makefile の代わりに、autotoolsを使用してプロジェクトをビルドすることについて読んでいます。残念ながら、私のプロジェクト構造が現在どのようになっているのかについて十分な洞察を与えてくれる例は見つかりませんでした。

プロジェクトのアプリケーション コードに含まれる 3 つのライブラリがあります。単一の構成スクリプトを使用して、アプリケーションとライブラリを作成 (およびインストール) する最良の方法を探しています。

私は過去数日間 autotools を使ってツールを使ってきましたが、最終的に大きな進歩を遂げました. 私が抱えている問題の 1 つは、メインのアプリケーション コードの前にコンパイルする必要がある 2 つのライブラリがあることです。これを行う方法がよくわかりません。私のディレクトリ構造は以下にあり、私のconfigure.acからのスニペットも同様です。

src/Makefileの前にcsv/Makefileとgtkworkbook/Makefileの両方をコンパイルする必要があります。これを指定する方法はありますか？現在、アプリケーションのコンパイル プロセス中に存在しないライブラリ (csv) に関するエラーが発生しています。

新しいリリースの問題のバージョン番号の急上昇にどのように対処するかを知りたいと思います。

マニュアルページなどの関連ファイルのバージョン番号をどのように処理しますか。

ソフトウェアはgnuツールチェーンで構築されているため、autoconf、automakeなどが利用可能であり、アプリケーションのバージョン番号に使用されます。情報を再利用できるようにします。

gitはvcsとして使用されます。

1つの可能性は、関連するすべてのファイルのバージョン番号と日付を置き換えるためにsed/awkを実行するMakefile.amに追加の新しいターゲットを導入することです。そのターゲットは、新しいリリースの開発の開始時（分岐直後）に一度呼び出すことができます。

次に、人々がプロジェクトのgitクローンを作成するとき、またはリリースtarballが実行されるときに、プロジェクトは正しい情報でビルドできます。もちろん、新しいリリースの開発を開始するときは、このmakeターゲットを実行することを忘れないでください。

もう1つのオプションは、sed / awkをdistターゲットのフックで置き換えることですが、これにより、プロジェクトのgitリポジトリが、関連付けられたファイルに正しいバージョン番号が関連付けられていない状態になります。

git履歴内に正しいバージョン番号も記録されるため、最初のソリューションを実行することをお勧めします。

sed / awkの置換を行うときは、「ファイル内」で行うか、autoconf/automakeツールのようにファイル内のテンプレートを使用するかを選択します。どちらの方法にも長所と短所があります。

関連ファイルのバージョン管理をどのように処理しますか。開発フェーズの開始時に変更しますか、出荷直前に変更しますか、ファイル内置換を行いますか、それともテンプレートを使用しますか？

THX。