어디서나 작동하도록 C++ 코드를 배포하는 방법에 대한 팁

Question

나는 이식 가능한 코드를 만드는 것에 대해 이야기하지 않습니다. 이것은 더 많은 배포 문제입니다. 중간 크기의 프로젝트가 있습니다. 공용 라이브러리 (예 : openssl, zlib 등)에 여러 가지 종속성이 있습니다. 그것은 내 컴퓨터에서 잘 컴파일되고 이제는 세상에 줄 시간입니다.

기본적으로 엔지니어링을 최상으로 구축하십시오. Windows, Linux, MacOSX 등의 설치 프로그램을 만들고 싶습니다. 코드를 ./configure 및 make (아마도 autoconf를 통해)으로 작동하도록 다운로드 할 수있는 타르 공을 만들고 싶습니다. 설치 프로그램을 만들 수있는 make 옵션을 사용하는 것은 케이크 위에 장식 될 것입니다. 크로스 컴파일을해도 Windows 설치 프로그램이 Linux에서 빌드 될 수 있습니다.

최상의 전략은 무엇입니까? 어디에서 가장 많은 시간을 보내고 싶습니까? 주요 초점이 autoconf일까요 아니면 도움이 될 수있는 다른 도구가 있습니까?

Answer 1

나는 CMake을 권하고 싶습니다. 장점 :

• 정적 라이브러리, 동적 라이브러리, 실행 파일 및 해당 종속성이있는 단순하고 복잡한 프로젝트를 작성하는 데는 매우 편리합니다.
• 이것은 플랫폼에 독립적이며 대부분의 컴파일러와 IDE를위한 makefile 및/또는 ide 프로젝트 파일을 생성합니다.
• Shared가 프로젝트의 일부인 경우 "libShared.so"및 "Shared.dll"과 같이 Windows와 UNIX의 차이를 추상화합니다 (예 : "cmake"는 각 플랫폼의 이름 차이를 처리합니다). 종속성을 정렬하지 않으면 링커 경로에 있음을 가정합니다.
• 사용자 시스템에서 필요한 컴파일러 및 타사 라이브러리를 조사하면 타사 라이브러리를 사용할 수없는 경우 구성 요소를 선택적으로 제거하거나 가장 일반적인 타사 라이브러리를 찾을 수있는 매크로가 포함 된 오류 메시지가 표시 될 수 있습니다.
• 위의 발견 된 매개 변수 (예 : 타사 라이브러리의 컴파일러 또는 버전)를 사용자가 변경할 수 있도록하는 간단한 GUI 또는 명령 줄에서 실행할 수 있습니다.
• 일반적인 단계 자동화를위한 매크로를 지원합니다.
• 설치 관리자를 만들 수있는 CPack이라는 구성 요소가 있습니다.이 도구는 단지 make install 명령 줄 일 뿐이라고 생각합니다. 사용하지 않았습니다.
• CTest 구성 요소는 부스트 테스트 또는 Google 테스트와 같은 다른 단위 테스트 라이브러리와 통합됩니다.

저는 CMake를 모든 용도로 사용합니다. Visual Studio를 사용한 간단한 테스트 프로젝트도 있습니다.

나는 autotools를 사용한 적이 없지만 많은 다른 사용자들이 cmake를 사용하기가 더 쉽다고 말했습니다. 이러한 이유로 KDE 프로젝트가 autotools에서 cmake로 옮겨졌습니다.

Answer 2

제가 작업하는 제품은 이것과별로 다릅니다. 우리는 autoconf 기반의 빌드 시스템을 사용하며 꽤 잘 작동합니다.

사용자가 가장 많은 시간을 보냅니다. 사용자를 지원합니다. 사용자 시스템에는 사용자가 실행될 때까지 예상하지 못하는 모든 종류의 주름이있을 수 있으며이를 지원하기 위해 추가 구성 옵션을 추가해야합니다. 시간이 지남에 따라, 우리가 의존하는 모든 라이브러리에 대해 include 및 lib 경로를 설정하는 옵션이 추가되었습니다. 다양한 버전의 라이브러리 (또는 코드에서 변경해야하는 것보다 한 버전에서 다른 버전으로 변경된 API)에서 다양한 이상한 글리치를 해결하기 위해 컴파일 플래그를 변경하는 옵션을 추가했습니다. 일부 BLAS 라이브러리 C 인터페이스를 사용하고 일부는 Fortran 인터페이스를 사용하므로 이론적으로는 동일한 라이브러리를 구현하더라도 약간 다른 점이 있습니다. 이 모든 것을 미리 예측할 수는 없으며 사용자가 설정할 옵션을 파악할 수 있도록 문서화가 필요합니다.

아, 설치 관리자는 일반적으로 OS에 의존적이기 때문에 (실제로는 쉘 스크립트가 아니고 CygWin이 필요하지 않는 경우) OS 설치에 의존하는 경향이 있습니다. 좋은 설치 프로그램을 작성하거나 수동으로 설정하는 사용자를 지원하는 데 시간이 걸리는 또 다른 영역입니다.

내 경험에 비추어 볼 때 (적어도 Linux-to-Windows의 경우, MacOS/X에 대한 확신이없는) 크로스 컴파일 설정은 여러 가지 빌드 시스템을 유지하는 것보다 훨씬 쉽습니다. 동기화.

OpenFOAM 프로젝트가 "승인 된"G ++ 컴파일러 및 다른 모든 구성 요소의 패키지와 함께 배포하는 상당히 큰 C++ 라이브러리에 사용하는 옵션이 있습니다. 다른 컴파일러에 대해 걱정해야합니다. 하지만 실제로는 하나의 OS에서만 작동합니다. Windows/MacOSX 버전은 미리 설정된 VMWare 이미지를 제공하는 것입니다. 어떤 경우에는 ...

Answer 3

사용 autotools를을 그것에 대해 말할 수 뭔가있다, 대부분의 사용자는 그들을 잘 알고있는 (즉, 그들은 ./configure를 & &이 & & 설치 할 수 있도록 실행하는 알)

• make dist를 사용하여 .tar.gz 파일을 만들고 컴파일하여 여러 시스템에서 작동하는지 테스트하십시오.

• Linux/Unix/Cygwin의 경우 설치 프로그램을 제공하지 마십시오 ... source tar.gz가 더 좋습니다. 어쨌든 각 리눅스 배포판에는 자체 포장 규칙이 있으며 대부분 autoconf 빌드를 사용하는 것으로 알고 있지만 사용자는 32 비트 또는 64 비트 시스템을 사용하거나 PPC 또는 Sparc를 통해 실행할 수 있으므로 걱정하지 않아도됩니다.

  는 어쩌면 그것은 가치가 바이너리를 제공하는 하나 뎁을 만들거나 그 다음 가장 인기있는 시스템 rpm으로하지만 더 ... Windows의 경우

• (네이티브, Cygwin에서하지 않음)합니다. Migw + 자동 설치는 매우 고통스럽고 Windows 사용자는 일반적으로 "다음 -> 다음 -> 다음"사용자 "wget ​​/ tar/configure/make/make-install"사용자 "Zip 또는 일부 설치 프로그램을 제공합니다. 거기.

  ... ZLIB 또는하려면 openssl이없는 기본적으로 가난한 Windows 사용자를 기억 그래서 당신은 당신의 패키지를 제공해야합니다. CMake 소개

...

대부분 Windows 플랫폼을 대상으로하거나 MSVC를 지원하고자한다면 아마도 고려해야 할 것입니다. 그렇지 않으면 autotools가 좋은 배포를 제공하고 대안을 구축합니다.