私はそれぞれ独自のautotools構造を持つ多くのサブモジュールを含むプロジェクトの「マスター」makefileを維持します。プロジェクトはさまざまな構成（たとえば、さまざまなバージョンのバックエンド用に構築）でテストされており、NFSまたはクロスコンパイラの同じホームディレクトリを使用してさまざまなプラットフォーム/アーキテクチャで構築できます。これはすべて、現在のソースチェックアウト（git repo clone）ワークスペースを取得し、ソースを現在のビルド設定とは別のディレクトリに「複製（*）」し、そのソースクローンをconfigure転送/autogen実行することによって行われます（元チェックアウトを汚染しない）。処理された後、自動化されたツールのサポートを受け、最終的にツリーで構築されます。
「（*）clone」部分はさまざまな方法で実装されています。たとえば、ソースワークスペースを「ソースレプリカ」にコピーするか、レプリカにディレクトリcp構造tarを作成し、プライマリワークスペースのソースファイルへの相対シンボリックリンクを入力します。 。ここにドラゴンがあります:)
自然ファイルで埋められたソースクローンは自給自足であり、自動作成タスク、特にdist（およびdistcheck）タスクによく渡されます。相対シンボリックリンクを「現状のまま」パッケージ化する「symlinkクローン」とは異なり、解凍後は意味のあるmake distすべての場所を指します。
シンボリックリンクの利点は、開発者がワークスペースでファイルを編集し、gitなどにコミットすることなく一度にすべて再構築できることです。つまり、開発の繰り返しサイクルを加速します（少なくとも新しいファイルが追加されない限り、再作成するだけです）。 「make」はすでに既存のコンテンツを編集しています）。さらに、同じファイルを複数回コピーするよりも、ストレージスペースと時間のオーバーヘッドがはるかに少なくなります。
だから質問は：元のソースへの相対シンボリックリンクで埋められたディレクトリを「make dist」することは可能ですか？たぶん「dist Hook」やタールボールの生成方法を無視する別の方法がありますか？ （distプロセスがソースディレクトリシンボリックリンクを逆参照してプライベートサブディレクトリに物理ファイルを生成する場合は許可されます。）
それとも、これは単に実現可能ではないので、私たちもケーキを食べることができませんか？ :)
（注）問題の「デフォルト」Makefileは次の場所にあります。https://github.com/42ity/FTY/)