라이브러리 컴파일을위한 C/C++ 협약/툴체인

Question

C/C++의 기본적인 문제점은 라이브러리 컴파일 영역에 있습니다. 예. 소프트웨어 A는 라이브러리 Z를 사용하므로 소프트웨어 Z를 컴파일하고 사용하거나 소프트웨어 A를 개발하기 전에 라이브러리 Z를 컴파일해야합니다.

많은 경우에 프로젝트를 구성한 다음 make + make install을 호출하는 개념이 있습니다. 예 : 당신은 당신의 명령 줄을 열고 다음을 입력 :

./configure 
make 
make install 

./configure 프로젝트의 최상위 디렉토리에있는 쉘 스크립트입니다. 모든 종속성이 시스템에 있는지 확인하고 이러한 종속성에 대한 경로를 저장한다고 가정합니다. 나중에 make는 수집 된 정보를 사용하여 컴파일러에 각각의 포함 경로와 라이브러리 위치 (예 : .so/.a 파일의 위치)를 제공 할 수 있습니다.

make은 I-dont-know에 의해 생성되고 XYZ 형식을 갖는 makefile에 의해 지정된대로 올바른 순서로 소스 파일을 컴파일하고 링크합니다. 물론, 컴파일/링크 자체가 아니라 실제 컴파일러와 링커를 호출하여 작업을 수행합니다.

make install은 결과 바이너리 파일을 가져 와서 시스템의 어딘가에 배치합니다 (예 : 프로젝트가 라이브러리 인 경우/usr/lib 또는 실행 파일의 경우/usr/bin). 현재 사용중인 프로젝트가 라이브러리 인 경우, 라이브러리의 헤더 파일을 가져 와서 시스템의 어딘가에 설치합니다.

이것은 비교적 복잡한 프로세스입니다. CMI를 사용하여 이러한 유형의 컴파일 프로세스를 나타냅니다 (CMI = configure-make-install). 또한, CMI 개념은 - 내가 알 수있는 한, 리눅스 세계에 특화된 개념이다. Windows 에서처럼 작동하지 않습니다 (예 : ./configure를 실행하는 데 사용할 수있는 셸이 없기 때문입니다. make는 심지어 gcc/g ++로 제한 될 수도 있지만, 그런 경우인지는 알 수 없습니다.

가장 중요하게는, 나는 어디에서 그걸 볼지조차 모릅니다. 또한 CMI 개념이 동시에 여러 버전의 라이브러리를 설치할 수 있는지 여부를 조사하고 싶습니다. 당신은 소프트웨어 B와 소프트웨어 C의 개발자라고 상상해보십시오. 소프트웨어 B와 C는 둘 다 라이브러리 Y에 의존하지만, B는 Y 1.0.x가 필요하고 C는 1.1.x가 필요합니다. make install이 라이브러리의 헤더 파일을 시스템의 어딘가에 배치하면 충돌이 발생하지 않습니까? 다시, 나는 내 자신에게 묻습니다. 어디서 볼 수 있습니까?

---

예제 라이브러리에 대해 설명해 드리겠습니다. libzip. 홈페이지에는 지원되거나 권장되는 컴파일러 또는 플랫폼이 명시되어 있지 않습니다. 지금 어떻게 하시겠습니까?

흥미롭게도 페이지는 MySQL Workbench가 libzip을 사용한다고 주장합니다. MySQL Workbench도 Windows 용으로 제공되므로 libzip을 Windows에서 컴파일 할 수 있다고 가정합니다.

나는 또한 그 libzip 관찰은 CMakeLists.txt및구성 스크립트와 함께 제공됩니다. 심지어 libya.pc.in CMake-template이 있는데, pkg-config 도구입니다. 또한 Makefile.am (그게 뭐든간에)과 Makefile.in (아마도 다른 CMake 템플릿)이 있습니다. 마지막으로 중요한 것은 m4 및 .m4 파일 (m4 폴더와 프로젝트의 루트 폴더 모두)에 폴더 m4와 .m4 파일이 있음을 알았습니다. 그러나 cmake-config.h.in, cmake-zipconf.h.in을 잊지 마십시오.(? 오른쪽)

사용을 Windows에서

• 적용하지 CMI 개념을 사용
  • : 당신이 libzip을 컴파일하려면

    그래서, 다음과 같은 대안을 고려해야합니다 어떤 종류의 컴파일러/IDE CMake를 생성할지 결정해야만하는 CMake, 어떤 종류의 메타 빌드 시스템 인

    • : gcc? MSVC? Mingw 또는 QTSDK/MingW?
  어쩌면 그

  M4는 GNU autoconf를 관련이있을 것으로 보인다 무엇이든 M4를 사용 (어떤 차이입니다). 나는 또한 위 목록에 추가 할 수 있다고 생각합니다.

  ((!) 참고가 :. 지금까지, 나는 현재 내가 컴파일 오류가 모든 종류의를 고정하고 비주얼 CMake + 스튜디오 2010의 조합을 사용하여 libzip 컴파일 시도)

  ---

  이 내 중앙 관측이다 :

  libzip은 간단한 라이브러리입니다. 그냥 지퍼 물건. 그러나 편집 작업에는 많은 도구가 필요하기 때문에 고급 프로그래머에게조차도 매우 어려운 작업입니다.

  또한 대부분의 도구에 대한 설명서가 부족합니다 (그렇지 않은 이유는 무엇입니까? 대답을 찾을 수있는 위치를 모르는 이유는 무엇입니까?). 예를 들어 버그 수정 CMake FindPackage-scripts 한숨과 같은 리버스 엔지니어링에 시간을 투자하지 않고도 대부분의 도구가 작동하지 않습니다.

  ---

  나는 그 것처럼 계속 될 수 있습니다. 나는 수많은 컴파일 개념에서 길을 잃었다. 모두 이 서로 관련이있다., 어떤 플랫폼과 컴파일러가 잘 작동하는지 등등.

  또 다른 예 : RetroShare. Windows is documented의 컴파일 프로세스에도 컴파일을 수행하는 것은 매우 어렵습니다. Windows에서의 RetroShare 컴파일에는 QtSDK/MingW, Cygwin 및 MingW/MSYS가 포함되어 있습니다. 이들 모두는 서로 다른 부품/종속성에 대한 것입니다. 이 도구들은 어떻게 함께 작동합니까?

  나는 완전히 잃어 버렸고 이런 종류의 문제를 다루는 방법과 이러한 모든 도구/툴체인/컴파일러/플랫폼을 고려한 심각한 피해로부터 당신을 보호하는 방법을 알려주시겠습니까?

  나는 매우 지능이 있습니까? 아니면 매우 바보입니까? 왜 이렇게 복잡합니까 (아니면 그렇지 않은가)?

Answer 1

"나는 이런 식으로 계속 나갈 수 있습니다."

약간이라고 혼동을 느낍니다. 몇 가지 구체적인 사항을 말씀 드리겠습니다.

"configure-make-install"프로세스는보다 일반적인 목적의 도구 인 make을 사용합니다. 즉, make와 makefile은 다른 방법으로 사용될 수 있습니다. 그것을 명심하십시오.

"만들기는 ( I-해달라고-알고에 의해 생성 형식 XYZ가있다 메이크에 의해 지정) 컴파일하고 올바른 순서로 원본 파일을 링크 할 책임이있다."

조만간 메이크 파일을 직접 작성하는 법을 배워야합니다. make는 C/C++ 프로그래머를위한 필수 도구 인 거의 유용한 빌드 시스템입니다. IDE를 사용하는 경우 이미 메이크 파일을 만들 수 있습니다. 여기서 작은 프로젝트 직접 작성 예시 메이크 같습니다

wx = `wx-config --cxxflags --libs` 

test1: main.cpp main.h window.o 
     g++ -Wall -g main.cpp window.o -o test1 $(wx) 

window.o: window.cpp window.h 
     g++ -Wall -g -c window.cpp -o window.o $(wx) 

첫번째 행 변수를 정의 링커 일부 플래그, 이는 그 후 두 번 사용된다. 명령 행에서 gcc를 사용하면 다음 두 비트가 친숙해야합니다. make없이이 프로젝트를 빌드하려면 먼저 g++ ...을 통해 window.o를 컴파일 한 다음 test1을 컴파일합니다. makefile을 사용하면 make을 실행하면됩니다. 몇 가지 개체 (.o) 파일을 프로젝트에 추가하면 매우 편리해 보입니다. 또한 하나의 메이크 파일에 다른 "타겟"을 쓸 수 있습니다. GNU 버전에 대한 공식 문서가 다양한 메이크업 자습서 주변, 그리고 :

http://www.gnu.org/software/make/manual/make.html

파악하기 어렵지 않다.

"를 설치하기는 결과 바이너리 파일을 소요하고 시스템의 어딘가에 그들에게 배치"

make install는 종래에 사용 된 메이크에서 그렇게 정의 된 대상입니다 구성 - 메이크업 설치 문맥. 이 빌드 트리에 있어야합니다 파일을 참조 (또는 다른 -

콜론 다음 대상으로 같은 줄에있어 무엇이든

install: test1 
    cp test1 /usr/local/bin/ 

가 전제 조건입니다 : 당신은 위 메이크에 그런 일을 추가 할 수 있습니다 target 지시문을 실행해야 함). 파일이 없거나 (빌드 된 이후에 선행 조건 중 일부가 변경된 경우) 동일한 이름의 대상이있는 경우 (이 경우 앞에 test1 - 전제 조건을 살펴보십시오) 해당 대상 지정 문은 다음과 같습니다. 먼저 실행하십시오.

"또한 CMI 개념은 - 내가 말할 수있는 한 - 리눅스 세계에 맞다."

아니요. 그러나 창 세계에는 약간 외계인입니다. 이는 종종 autotools과 관련하여 구성 스크립트 및 해당 makefile을 생성하는 데 사용할 수 있습니다. mingw이 설치된 경우 Windows에서 CMI 패키지를 사용할 수 있습니다.

는

CMake은 본질적으로 단지 다른 메이크업과 같은 일이다 "종류의 메타 빌드 시스템이다 CMake를 사용합니다." make은 메이크 파일에서 명시 적으로 호출 된 경우에만 gcc를 사용합니다. makefile은 쉘 스크립트가 할 수있는 일에 대해 컴파일러를 실행하는 등의 일을 할 수 있도록 작성 될 수 있습니다. CMake는 더 이식성이 뛰어나고 플랫폼에 어긋나지 만 사용자 친화적 인 사람이되기를 원합니다. 어떤 사람들은 그것을 더 좋아합니다.

"make install을 통해 라이브러리의 헤더 파일이 시스템의 어딘가에 배치되면 충돌이 발생하지 않습니까?"

이상적으로 아니오. autotools ("CMI") 설정의 요점은 패키저가 이와 같은 문제를 처리 할 수있는 메커니즘을 구현할 수 있도록하는 것입니다. 동일한 라이브러리의 여러 버전을 설치할 수 있습니다. WRT 헤더가 변경되면 라이브러리 자체와 마찬가지로 (잘하면) 이전 버전과의 호환성을 유지합니다. 그렇지 않다면 명시적인 표시가 있어야합니다 ('버전 2는 버전 1과 호환되지 않습니다!'). 그런 일이 발생하면 두뇌를 가진 사람은 처음부터 버전 2에 대해 고유 한 헤더를 가지며 API의 헤더를 참조합니다 .

Answer 2

또한 사용하는 것을 이해하는 것이 도움이 될 수있다 : http://www.elpauer.org/stuff/learning_cmake.pdf