![Unix 및 Linux 생태계의 autoconf 구성 스크립트에 혁신이 거의 없는 이유는 무엇입니까? [폐쇄]](https://linux55.com/image/137742/Unix%20%EB%B0%8F%20Linux%20%EC%83%9D%ED%83%9C%EA%B3%84%EC%9D%98%20autoconf%20%EA%B5%AC%EC%84%B1%20%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8%EC%97%90%20%ED%98%81%EC%8B%A0%EC%9D%B4%20%EA%B1%B0%EC%9D%98%20%EC%97%86%EB%8A%94%20%EC%9D%B4%EC%9C%A0%EB%8A%94%20%EB%AC%B4%EC%97%87%EC%9E%85%EB%8B%88%EA%B9%8C%3F%20%5B%ED%8F%90%EC%87%84%5D.png)
./configure를 호출할 때 특히 종속성이 누락되고 후속 호출이 발생하는 경우 많은 시간이 낭비됩니다.
재사용을 위해 구성 스크립트의 결과를 캐싱하는 것을 참조하는 이 주제에 대한 많은 스레드를 읽었습니다.다른구성 스크립트는 결과가 오래되고 동기화되지 않아 오류가 발생하기 쉬우며 결과를 공유하는 일반 구현을 만드는 것은“힘들다”[1].
나는 구성 스크립트가 이미 캐싱을 지원한다는 것을 알고 있지만 이는기본적으로 비활성화되어 있습니다.[2].
배포판이 이미 상호 종속성을 이해하는 패키지 관리자를 제공하고 모든 공통(또는 가장 일반적인) 소스 종속성이 무엇인지 이미 알고 있다면 배포판이 캐시 구성을 위한 일종의 표준을 제공하지 않는 이유는 무엇입니까? 특정 조건이 주어지면 패키지 관리자는 이러한 테스트 중 많은 부분을 전혀 실행할 필요가 없다고 평가할 수 있다고 가정할 수 있습니다. 또는 적어도 구성 중에 문제가 발생하지 않는 한 그렇지 않습니다.
다른 많은 경쟁 빌드 시스템이 있지만 저는 Config가 여전히 가장 인기가 있다는 것을 알았습니다. 이러한 스크립트는 셸 기반의 단일 스레드이며 오류가 발생하기 쉽고 진단 정보를 암호화하거나 제공하지 않는 경우가 많으며 매우 느린 경우가 많습니다. 구성의 일부도 아닌 종속성 누락으로 인해 구성 스크립트가 실패하거나 컴파일이 실패하는 것은 드문 일이 아닙니다.
이 문제를 해결한 배포판이 있나요? 예를 들어, Gentoo는 많은 네이티브 컴파일을 수행합니다. 그들은 이것을 최적화할 것인가?
나는 빌드 시스템 조언을 찾고 있는 것이 아니라 현대 프로젝트가 여전히 autoconf 및 구성에 크게 의존하는 이유에 대한 역사적 또는 문화적 관점을 찾고 있습니다. 이는 아마도 의견의 영역에 속할 가능성이 크지만, 건축 관행, 회사 정책, 백발의 관습에 기초하여 공정한 사실을 가질 수도 있는 매우 흥미로운 주제라고 생각합니다.
메일링 리스트에 대해서도 유사한 주장이 가능합니다. 메일링 리스트는 웹상의 최신 공동 작업 형태에 비해 구식이지만 단순하고 단순함을 고려하여 거의 변경 사항이 없기 때문에 항상 해왔던 것과 똑같은 기능을 수행합니다. 어쩌면 autoconf도 비슷한 운명을 가지고 있을까요? (면책조항: 저는 실제로 메일링 리스트를 좋아합니다. 어떤 불만이라도 메일 클라이언트 측의 열악한 지원으로 인해 발생합니다.)
답변1
제 생각에는 "혁신"을 구성하는 요소가 사람마다 다르고(그리고 그것이 좋은 것인지!) autoconf대부분 언어와 아키텍처에 구애받지 않도록 설계되었기 때문에 모든 대답은 최소한 약간의 추측입니다. 변경하려는 욕구를 낮게 유지하는 관성: 일부 구성 스크립트는 수십 년이 지났을 수 있으며 사람들은 작동하는 것을 다시 작성하고 싶어하지 않는다는 점을 고려해야 합니다.
직면한 제한 사항 중 일부는 autoconf구조적입니다. 예를 들어 멀티스레딩을 확인하는 단계에서 멀티스레딩을 사용하는 방법은 무엇입니까? libfoo버전 1.8이 필요하다고 주장하는 프로그램에서 버전 2.5를 사용할 수 있습니까 ? 당신이 언급한 다른 문제는 종속성 사양이 부족하여 발생하는 경우가 많습니다. 직접 종속성을 모두 나열하는 것을 잊어버린 구성 스크립트가 많이 있습니다. 마지막으로, autoconf관리자 수가 상당히 제한되어 있어 큰 변화를 주기가 어려운 것 같습니다.
어떤 면에서 패키지 관리자는 혁신이 일어나는 곳입니다. 동일한 라이브러리의 다른 버전이 필요한 다른 패키지와 같은 개념을 처리하고, 더 이상 사용할 수 없는 종속성에 대한 해결 방법을 식별하고, (젠투와 같은 소스 컴파일 배포판의 경우) 구성 스크립트 및 소스 코드를 정리하여 제대로 작동하도록 패치를 제공할 수 있습니다. .
답변2
물론 Autoconf는 결과를 캐시하므로 올바르게 사용하면 거의 실행되지 않습니다 configure.
내 schilytools 프로젝트(>4000개 소스 파일, ~770000줄의 코드)는 현재 약 800개의 자동 구성 테스트. 모든 테스트를 실행하는 데 2.7GHz Intel 노트북에서는 28초가 걸렸고, 1995 HP-9000 피자 상자에서는 2~3시간, 1996 Sun3/60에서는 4~6시간, 1996 Sun3 On/60 it에서는 4~6시간이 걸렸습니다. 4~6시간 정도 걸립니다. Vax 11/780의 날.
구성 스크립트가 대략적으로만 변경되었으므로 걱정할 필요가 없습니다. 1년에 5번 configureIntel 노트북에서 재실행하는 데는 다른 모든 테스트가 캐시되므로 4초 밖에 걸리지 않습니다. 물론 구성 결과가 만료된 경우에만 다시 실행되는 make규칙이 있습니다.configure
하류 사람들은 다른 견해를 가지고 있습니다. 그들은 이 프로젝트를 configure연간 30회, 연간 15분이 소요되는 일회성 패키지로 취급합니다 .
반대편에서 1년에 25초만 기다리면 되는데...
그러면 문제는 다운스트림 사람들이 소프트웨어를 어떻게 사용하느냐가 됩니다.