가능한 경우 system/distro 제공 라이브러리에 대한 코드. 이렇게하면 해당 배포판에서 제품을 출하하는 것이 가장 쉽습니다.
그러나 상업용 응용 프로그램을 빌드하는 경우 리눅스 배포본의 종류가 너무 많아서 각 배포판별로 많은 응용 프로그램 빌드를 유지해야 할 수도 있습니다. 반드시 나쁜 것은 아니므로 배포자의 패키지 관리 시스템을보다 깔끔하게 통합 할 수 있습니다.
당신이 할 수없는 경우 당신이 가지고있는 각 타사 종속성의 소스를 다운로드하고 실행 파일에 링크 된 정적 lib에 해당 종속성의 빌드를 통합하는 것이 매우 쉽습니다. 그렇게하면 연결 대상을 정확히 알 수 있지만 실행 파일 크기를 늘릴 수있는 단점이 있습니다. 배포판에서 제공하지 않는 특정 라이브러리 (또는 버전)가 필요한 경우에도 필요합니다.
다양한 유닉스 시스템에서 코드를 빌드하려면 GNU autoconf과 automake을 사용하는 것이 현명 할 것입니다. 이것들은 프로젝트에 configure 스크립트와 makefile을 구성하는 데 도움을 주어 실질적으로 모든 유닉스 시스템에 구축되도록합니다.
pkg-config도 있습니다.이 라이브러리는 적절한 라이브러리 (pkg-config를 지원하는 libs)에 포함하고 링크하는 데 도움이되는 Linux 배포판에서 상당히 많이 사용되고 있습니다.
Subversion을 사용하여 소스를 관리하는 경우 대부분의 Subversion 저장소가 자체 코드 및 "공급 업체"코드를 관리하는 데 사용하는 "규칙"이 있습니다.
대부분의 svn 리포지토리에는 트렁크와 함께가는 "공급 업체"트리가 있으며, & 태그 트리가 있습니다. 이것이 모든 타사 공급 업체 코드의 선두입니다. 이 디렉토리에는 사용하는 각 라이브러리에 대한 디렉토리가 있습니다. 예 :이 libs와 각각의 아래에는
branches/
tags/
trunk/
vendor/somelib
vendor/anotherlib
각 라이브러리 버전 저장소에서 최신 버전의 "현재"디렉토리에 대한 디렉토리입니다.
vendor/somelib/1.0
vendor/somelib/1.1
vendor/somelib/current
그런 다음 프로젝트의 나무는 다음과 같이 배치해야합니다
트렁크/소스 # 모든 코드 여기 트렁크/libs와 번호 모든 벤더 코드 여기에
libs와 디렉토리해야에 비어 있지만 통해, 그와 관련된 svn:externals 메타 데이터가됩니다
svn propedit svn:externals trunk/libs
이 속성의 내용 것은 어떤 것 의 라인을 따라 가지 (서브 버전 1.5을 가정) :
^/vendor/somelib/current somelib
^/vendor/anotherlib/1.0 anotherlib
이 당신이 당신의 코드의 파괴를 체크 아웃 할 때 또한 트렁크/libs와 디렉토리에 공급 업체 라이브러리를 체크 아웃 것을 의미한다. 그래서 체크 아웃 할 때는 다음과 같습니다
trunk/source
trunk/libs/somelib
trunk/libs/anotherlib
이것은 Subversion Book에 (아마도 훨씬 더) 설명되어 있습니다. 특히 vendor branches과 externals을 다루는 부분.