Fooと呼ばれる新しい言語を設計し、そのためのコンパイラを作成しているとします。その長所は、コンパイラの実装に特に適していることを目的としています。古典的なアプローチは、コンパイラの最初のバージョンをCで記述し、それを使用して2番目のバージョンをFooで記述し、その後、自己コンパイルすることです。
これは、バイナリのバックアップコピーを保持するように注意する必要があることを意味します（ソースのバックアップコピーのみを保持する必要があるほとんどのプログラムとは対照的です）。言語が最初のバージョンから進化した後、バイナリのすべてのコピーを失った場合、現在のバージョンをコンパイルできるものは何もありません。だからそれでいい。
ただし、LinuxとWindowsの両方をサポートすることを目的としているとします。実際に両方のプラットフォームで実行されている限り、各プラットフォームでコンパイルできます。問題はありません。ただし、1つのプラットフォームでバイナリを失った（または攻撃者によって侵害されたと疑う理由があった）とします。今問題があります。また、サポートされているすべてのプラットフォームのバイナリを保護する必要があることは、私が満足しているよりも少なくとも1つ多くの障害点です。
1つの解決策は、どちらかのプラットフォームのバイナリが両方のプラットフォームをターゲットにできるように、クロスコンパイラにすることです。
これは思ったほど簡単ではありません-バイナリ出力形式の選択に問題はありませんが、各プラットフォームはCヘッダーファイルの形式でシステムAPIを提供します。これは通常、ネイティブプラットフォームにのみ存在します。たとえば、保証コードはありません。 Windowsに対してstdio.hコンパイルされたものは、Linuxバイナリ形式にコンパイルされた場合でもLinux上で機能します。
おそらく、この問題は、LinuxヘッダーファイルをWindowsボックスにダウンロードし、Windowsバイナリを使用してLinuxバイナリをクロスコンパイルすることで解決できる可能性があります。
私が見逃しているその解決策に関する警告はありますか？
別の解決策は、FooをポータブルCにコンパイルし、メインのFooコンパイラに必要な言語のサブセットのみを受け入れ、最小のエラーチェックを実行し、最適化を行わない、Pythonで個別の最小ブートストラップコンパイラを維持することです。したがって、後続の言語バージョン間でそれを維持するのにそれほど費用がかからないほど単純なままです。
繰り返しますが、私が見逃しているそのソリューションに関する警告はありますか？
過去にこの問題を解決するために人々はどのような方法を使用しましたか？