Foo라는 새로운 언어 용 컴파일러를 설계하고 작성했다고 가정합니다. 그 중 장점은 컴파일러 구현에 특히 유용하기위한 것입니다. 고전적인 접근법은 컴파일러의 첫 번째 버전을 C로 작성한 후이를 사용하여 Foo에서 두 번째 버전을 작성한 후 자체 컴파일합니다.크로스 플랫폼 컴파일러 부트 스트랩
이것은 원본의 백업 복사본 만 보관해야하는 대부분의 프로그램과는 달리 바이너리의 백업 복사본을 유지해야한다는 것을 의미합니다. 언어가 첫 번째 버전에서 멀어지면 바이너리의 모든 복사본을 잃어 버리면 현재 버전을 컴파일 할 수 없습니다. 그러면 그렇게 해.
그러나 Linux와 Windows를 모두 지원한다고 가정합니다. 실제로 두 플랫폼 모두에서 실행되는 한 각 플랫폼에서 문제없이 컴파일 할 수 있습니다. 그러나 한 플랫폼에서 바이너리를 잃어버린다면 (또는 공격자가 침입했다고 의심 할만한 이유가있는 경우); 지금 문제가 있습니다. 그리고 지원되는 모든 플랫폼에 대해 바이너리를 보호해야한다는 점이 내가 느끼는 것보다 적어도 하나 더 많은 오류 지점입니다.
한 가지 해결책은 크로스 컴파일러로 만들어 두 플랫폼에서 바이너리가 두 플랫폼 모두를 대상으로 할 수 있도록하는 것입니다.
이진 출력 형식을 선택하는 데 문제가 없지만 각 플랫폼은 C 헤더 파일 형태로 시스템 API를 제공합니다. 시스템 API는 일반적으로 고유 플랫폼에만 존재합니다. Windows stdio.h
에 대해 컴파일 된 보증 코드가 Linux 바이너리 형식으로 컴파일 된 경우에도 Linux에서 작동합니다.
아마도이 문제는 Linux 헤더 파일을 Windows 상자에 다운로드하고 Windows 바이너리를 사용하여 Linux 바이너리를 크로스 컴파일하면 해결할 수 있습니다.
누락 된 해결책이있는주의 사항이 있습니까?
또 다른 해결책은 Foo를 이식 가능한 C로 컴파일하고 메인 Foo 컴파일러가 필요로하는 언어의 하위 집합 만 받아들이고 최소한의 오류 검사 및 최적화를 수행하지 않고 별도의 최소 부트 스트랩 컴파일러를 Python에서 유지하는 것입니다. 따라서 부트 스트랩 컴파일러는 후속 언어 버전 전반에 걸쳐 유지 보수가 비용이 많이 들지 않을 정도로 간단하게 유지됩니다.
다시 말씀 드리지만 해결책이 누락되었습니다.
과거에이 문제를 해결하기 위해 사람들은 어떤 방법을 사용 했습니까?
정말 문제입니까? 분명히 해결책은 "원래 소스 코드를 유지 보수하기 위해 리비전 컨트롤을 사용하는 것"입니다. –
왜 바이너리를 잃어 버릴 까 걱정하지? 아직도 원래 소스가 있니? 그리고 Foo 컴파일러가없는 시스템에서 컴파일러를 부트 스트랩 할 수 있도록 원래의 C 소스 코드를 배포해야합니다. –
시간이 지남에 따라 언어는 컴파일러의 원래 C 버전이 더 이상 이해할 수없는 방식으로 발전 할 것이기 때문에. – rwallace