[build] Autotools, Cmake 및 Scon의 차이점은 무엇입니까?

사실 Autotools의 진정한 ‘절약의 은총’은 모든 GNU 프로젝트가 주로 사용하는 것입니다.

Autotools 관련 문제 :

• ARCANE m4 매크로 구문은 “호환성”등을 테스트하기위한 자세한 트위스트 쉘 스크립팅과 결합되었습니다.
• 주의를 기울이지 않으면 크로스 컴파일 기능을 엉망으로 만들 것 입니다 (Nokia는 Semoatch / Scratchbox2를 사용 하여 Maemo / Meego에 대한 매우 깨진 Autotools 빌드 설정을 회피했습니다.) 이유는 테스트에서 고정 된 고정 경로를 가지고 있기 때문에 sysroot 사양을 따르지 않고 호스트 시스템에서 항목을 가져 오기 때문에 크로스 컴파일 지원을 중단하는 것입니다. 크로스 컴파일 지원을 중단하면 OpenEmbedded와 같은 코드에서 코드를 사용할 수 없게되고 대상이 아닌 크로스 컴파일러에서 릴리스를 빌드하려는 배포에서 “재미있게”만듭니다.
• NOBODY가 현재이 시대와 거의 모든 생산에서 사용 하는 고대의 깨진 컴파일러 문제에 대해 엄청난 양의 테스트를 수행합니다 . 진정한 고대 버전의 Solaris, AIX 등에서 glibc, libstdc ++ 또는 GCC와 같은 것을 빌드하지 않는 한 테스트는 시간 낭비이며 위에서 언급 한 것과 같은 많은 잠재적 인 손상의 원인이됩니다.
• Windows 시스템에 사용할 수있는 코드를 빌드하기 위해 Autotools 설정을 얻는 것은 상당히 고통스러운 경험입니다. (Windows에서는 거의 사용하지 않았지만 교차 플랫폼 코드를 개발하는 경우 심각한 문제입니다.)
• 그것이 깨질 때, 당신은 스크립팅을 작성한 사람이 당신의 빌드를 분류하기 위해 잘못한 것들을 정리하려고 꼬리를 쫓는 데 HOURS 를 쓸 것입니다 (실제로 이것이 내가하려고하는 것입니다. Autotools를 완전히 찢어 라-이번 달의 나머지 부분에서 혼란을 해결할 충분한 시간이 있는지 의심 스럽다 …)이를 입력하면서 지금 당장 작업 할 수 있습니다 Apache Thrift는 교차하지 않는 BROKEN 빌드 시스템 중 하나 -엮다.)
• “정상적인”사용자는 실제로 “./configure; make”를하지 않을 것입니다. 많은 것들을 위해, 그들은 PPA 나 유통 업체와 같은 누군가가 제공 한 패키지를 가져올 것입니다. “일반”사용자는 개발자가 아니며 많은 경우에 타르볼을 잡지 않습니다. 그것은 거기에 해당 될 것이라고 추정하기 위해 모든 사람들이 멍청한 짓입니다. 타르볼을 사용하는 일반적인 사용자는 일을하는 개발자이므로 파손이있는 경우 엉망이됩니다.

그것은 대부분의 경우 작동합니다 … Autotools에 대해 말할 수있는 모든 것입니다. 기본 핵심 툴체인 코드와 관련하여 GNU 프로젝트에만 관련된 몇 가지 문제를 해결하는 시스템입니다. (편집 (2014년 5월 24일) : 관심이 유형의 잠재적 것을 주목해야한다 BAD 부분적으로 당신이 생각에서하고 정확한, 현대적인 시스템을 막아야 Heartbleed와 소개 – 걱정 될 일이 정말Autotools가 해결하는 많은 부분을 다루는 비즈니스가 없습니다. GNU는 아마도 Heartbleed에서 일어난 일에 비추어 코드베이스를 과도하게 제거해야 할 것입니다.) 프로젝트를 수행하는 데 사용할 수 있으며 Linux를 제외한 다른 곳에서는 작동하지 않을 작은 프로젝트에 적합합니다. GNU 툴체인이 올바르게 작동하고 있습니다. 성명은 “잘 리눅스와 통합한다”는 것을 매우 대담한 진술과 아주 잘못된 . 그것은 GNU 툴 슈트와 합리적으로 잘 통합되고 IT가 목표와 관련된 문제를 해결합니다.

이것은 여기 스레드에서 논의 된 다른 옵션에 문제가 없다고 말하는 것은 아닙니다.

SCons는 Make / GMake / etc를 대체합니다. 그리고 꽤 멋져 보이지만 모든 것이 고려됩니다 …

• 여전히 실제로 POSIX 전용 도구에 가깝습니다. Autotools를 사용하는 것보다 MinGW가 Windows를 사용하여 Windows를 구축하는 것이 더 쉬울 수 있지만 POSIX 작업을 수행하는 데 실제로 더 적합하며이를 사용 하려면 Python 및 SCons를 설치해야 합니다.
• Scratchbox2와 같은 것을 사용하지 않으면 크로스 컴파일에 문제가 있습니다.
• 자체 비교에서 CMake보다 느리고 안정적입니다. 그들은 SCons에 비해 반감기 (POSIX 측은 make / gmake to build …를 만들 필요가 있습니다)의 CMake에 대한 부정적인 결과를 낳습니다. (여담으로, 당신이 필요로하는 경우에 있는지 다른 솔루션에 비해 훨씬 확장, 당신은 당신의 프로젝트가 너무 복잡 여부를 스스로 질문해야한다 …)

이 스레드에서 CMake에 제공된 예제는 약간 가짜입니다.

하나…

• 새로운 언어를 배워야합니다.
• Make, SCons 또는 Autotools에 익숙하다면 반 직관적 인 것들이 있습니다.
• 구축하려는 시스템에 CMake를 설치해야합니다.
• 미리 빌드 된 바이너리가없는 경우 견고한 C ++ 컴파일러가 필요합니다.

사실, 당신의 목표는 당신이 여기에서 선택한 것을 지시해야합니다.

• 유효한 작업 바이너리를 생성하려면 많은 깨진 툴체인 을 처리해야 합니까? 그렇다면, 위에서 언급 한 단점을 알고 Autotools를 고려할 수 있습니다. CMake는이 많은 것에 대처할 수 있지만 Autotools보다 걱정이 적습니다. SCons는 그것에 대해 걱정하도록 확장 될 수 있지만 기본 답변은 아닙니다.
• Windows 대상에 대해 걱정할 필요가 있습니까? 그렇다면 Autotools는 문자 그대로 실행되지 않아야합니다. 그렇다면 SCons가 좋은 선택이 아닐 수도 있습니다. 그렇다면 CMake는 확실한 선택입니다.
• 당신은 크로스 컴파일에 대해 걱정할 필요 (범용 애플 리케이션 / 라이브러리 등 구글 Protobufs, 아파치 드리프트, 같은 일을해야합니까 해야한다 … 이것에 대해 관심을)? 그렇다면 Autotools 가Windows에 대해 걱정할 필요가없는 한 귀하를 위해 일하십시오. 그러나 상황이 바뀌면 구성 시스템을 유지 관리하는 데 많은 시간을 소비하게됩니다. SCons는 Scratchbox2를 사용하지 않는 한 현재로서는 거의 이동이 불가능합니다. 실제로 크로스 컴파일을 처리하지 않으며 확장 성을 사용하고 다음과 같은 방식으로 유지해야합니다. 당신은 Automake와 함께합니다. 그렇다면 CMake는 샌드 박스에서 누출에 대해 걱정할 필요없이 크로스 컴파일을 지원하고 Scratchbox2와 함께 작동하거나 사용하지 않고 OpenEmbedded와 잘 통합되므로 CMake를 고려할 수 있습니다 .

많은, 많은 프로젝트가 qmake, Autotools 등을 버리고 CMake로 옮기는 이유가 있습니다. 지금까지 CMake 기반 프로젝트가 크로스 컴파일 상황이나 VisualStudio 설정으로 떨어지거나 프로젝트가 Windows 전용 또는 OSX 전용 부분을 설명하지 않았기 때문에 소량 만 정리하면됩니다. 코드베이스에. 나는 정말 SCons는의 아웃 프로젝트 – 기반 기대할 수 없습니다와 나는 완전히 1 / 3 이상의 Autotools가 프로젝트 찍었을 것으로 예상 뭔가 배제가 하나 또는 Scratchbox2를 구축하는 호스트를 제외한 모든 컨텍스트를 마우스 오른쪽 버튼으로 구축하는 것을 잘못.

---

답변