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

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를 구축하는 호스트를 제외한 모든 컨텍스트를 마우스 오른쪽 버튼으로 구축하는 것을 잘못.

도구를 사용하는 사람간에 중요한 차이점이 있어야합니다. Cmake는 소프트웨어를 빌드 할 때 사용자가 사용해야하는 도구입니다. autotools는 SuS 호환 시스템에서 사용할 수있는 표준 도구 만 사용하여 소프트웨어를 빌드하는 데 사용할 수있는 배포판 타르볼을 생성하는 데 사용됩니다. 즉, autotools를 사용하여 작성된 tarball에서 소프트웨어를 설치하는 경우 autotools를 사용하지 않는 것 입니다. 당신이 Cmake를 사용하는 소프트웨어를 설치하는 경우 반면에, 당신이 하는 Cmake를 사용하여이 소프트웨어를 구축하려면 설치되어 있어야합니다.

대부분의 사용자는 상자에 autotools를 설치할 필요가 없습니다. 역사적으로 많은 개발자들이 조작 된 tarball을 배포하여 사용자가 autoconf를 실행하여 configure 스크립트를 다시 생성해야했기 때문에 많은 혼란이있었습니다. 이는 패키징 오류입니다. 대부분의 주요 Linux 배포판은 기본적으로 어떤 버전도 설치하지 않아야 할 때 여러 버전의 autotools를 설치한다는 사실로 인해 더 많은 혼란이 발생했습니다. tarball을 구축하는 대신 버전 제어 시스템 (예 : cvs, git, svn)을 사용하여 소프트웨어를 배포하려고 시도하는 개발자로 인해 더 많은 혼란이 발생합니다.

GNU 코딩 표준에 관한 것이 아닙니다.

autotools의 현재 장점, 특히 automake와 함께 사용하면 Linux 배포판 빌드와 매우 잘 통합된다는 것입니다.

예를 들어 cmake를 사용하면 항상 "DCMAKE_CFLAGS 또는 필요한 -DCMAKE_C_FLAGS입니까?" 아니요, "-DCMAKE_C_FLAGS_RELEASE"도 아닙니다. 또는 -DCMAKE_C_FLAGS_DEBUG. 혼동 스럽습니다-autoconf에서는 ./configure CFLAGS = "-O0 -ggdb3"에 있습니다.

빌드 인프라와의 통합에 SCons는 당신이 사용할 수 없다는 문제가있다 make %{?_smp_mflags}, _smp_mflags대략 시스템 전원을 (관리자가 설정할 수 있음)을 확장한다는 RPM 매크로되는이 경우입니다. 사람들은 -jNCPUS와 같은 것을 환경을 통해 여기에 넣습니다. scons가 작동하지 않으므로 scons를 사용하는 패키지는 일련의 배포판에만 직렬화 될 수 있습니다.

Autotools에 대해 알아야 할 중요한 것은 일반적인 빌드 시스템이 아니라 GNU 코딩 표준을 구현한다는 것입니다. 모든 GNU 표준을 준수하는 패키지를 만들려면 Autotools가 훌륭한 작업 도구입니다. 그렇지 않으면 Scon 또는 CMake를 사용해야합니다. (예를 들어, 이 질문을 참조하십시오 .)이 일반적인 오해는 Autotools에 대한 대부분의 좌절에서 비롯된 것입니다.

개발자의 관점에서 볼 때 cmake는 현재 가장 사용하기 쉬운 반면 사용자 관점에서 autotools는 큰 장점이 있습니다.

autotools는 단일 파일 구성 스크립트를 생성하고이를 생성하는 모든 파일은 분배와 함께 제공됩니다. grep / sed / awk / vi의 도움으로 이해하고 수정하기 쉽습니다. 이 파일을 / usr / share / cmak * / Module에있는 Cmake와 비교하면 관리자 액세스 권한이 없으면 사용자가 수정할 수 없습니다.

따라서 무언가가 제대로 작동하지 않으면 일반적으로 빌드 시스템을 이해하지 않고도 표준 유닉스 도구 (grep / sed / awk / vi 등)를 망치로 사용하여 쉽게 "고정"할 수 있습니다.

cmake 빌드 디렉토리를 조사하여 무엇이 잘못되었는지 알아 본 적이 있습니까? 위에서 아래로 읽을 수있는 간단한 셸 스크립트와 비교할 때 생성 된 Cmake 파일을 따라 진행중인 작업을 찾는 것은 매우 어렵습니다. 또한 CMake를 사용하여 FindFoo.cmake 파일을 수정하려면 CMake 언어에 대한 지식이 있어야 할뿐만 아니라 수퍼 유저 권한이 필요할 수도 있습니다.