C ++ 라이브러리의 디렉토리 구조

C ++ 라이브러리에서 작업 중입니다. 궁극적으로 몇 가지 예제 및 Python 바인딩 과 함께 여러 플랫폼 (적어도 Linux 및 Windows)에서 공개적으로 사용할 수 있도록 만들고 싶습니다 . 작업은 훌륭하게 진행되고 있지만 현재 프로젝트는 매우 지저분하고 Visual C ++ 에서만 빌드되고 다중 플랫폼이 아닙니다.

따라서 정리가 필요하다고 생각합니다. 가장 먼저 개선하고 싶은 것은 프로젝트의 디렉토리 구조입니다. 여러 플랫폼에서 쉽게 컴파일 할 수 있도록 Automake 도구에 적합한 구조를 만들고 싶지만 이전에 사용한 적이 없습니다. 여전히 Visual Studio에서 (대부분의) 코딩을 수행 할 것이므로 Visual Studio 프로젝트 및 솔루션 파일도 보관할 어딘가가 필요합니다.

"C ++ 라이브러리 디렉토리 구조"와 같은 용어로 Google을 검색했지만 유용한 것은없는 것 같습니다. 매우 기본적인 지침을 찾았지만 명확한 해결책은 없습니다.

일부 오픈 소스 라이브러리를 살펴보면서 다음을 생각해 냈습니다.

\mylib
    \mylib <source files, read somewhere to avoid 'src' directory>
        \include? or just mix .cpp and .h
    \bin <compiled examples, where to put the sources?>
    \python <Python bindings stuff>
    \lib <compiled library>
    \projects <VC++ project files, .sln goes in project root?>
    \include? 
    README
    AUTHORS
    ...

저는 다중 플랫폼 개발 / 오픈 소스 프로젝트에 대한 경험이 없거나 거의 없었으며 그러한 프로젝트를 구성하는 방법에 대한 좋은 지침을 찾을 수 없다는 사실에 상당히 놀랐습니다.

일반적으로 그러한 도서관 프로젝트를 어떻게 구성해야합니까? 읽기를 권장하는 CA는 무엇입니까? 좋은 예가 있습니까?

Unix 라이브러리에서 매우 일반적인 한 가지는 다음과 같이 구성되어 있다는 것입니다.

./         Makefile and configure scripts.
./src      General sources
./include  Header files that expose the public interface and are to be installed
./lib      Library build directory
./bin      Tools build directory
./tools    Tools sources
./test     Test suites that should be run during a `make test`

다음과 같은 경우 기존 Unix 파일 시스템을 다소 반영합니다 /usr.

/usr/src      Sometimes contains sources for installed programs
/usr/include  Default include directory
/usr/lib      Standard library install path
/usr/share/projectname   Contains files specific to the project.

물론 /usr/local이것은 (GNU autoconf의 기본 설치 접두사)로 끝날 수 있으며이 구조를 전혀 고수하지 않을 수 있습니다.

엄격하고 빠른 규칙은 없습니다. 저는 개인적으로 이런 식으로 정리하지 않습니다. ( ./src/예를 들어 가장 큰 프로젝트를 제외하고 는 디렉토리를 사용하지 않습니다. 또한 자동 도구를 사용하지 않고 대신 CMake를 선호합니다.)

제 제안은 다음과 같은 디렉토리 레이아웃을 선택해야한다는 것입니다. 과 여러분의 팀 에게 적합한 입니다. 선택한 개발 환경, 빌드 도구 및 소스 제어에 가장 적합한 작업을 수행하십시오.

도움이 될만한 최근에 본 멋진 컨벤션이 있습니다 : The Pitchfork Layout (또한 GitHub ).

요약하면, 하위 섹션 1.3 에는 다음과 같이 명시되어 있습니다.

PFL은 프로젝트 트리의 루트에 표시되어야하는 여러 디렉토리를 규정합니다. 모든 디렉토리가 필요한 것은 아니지만 용도가 지정되어 있으며 파일 시스템의 다른 디렉토리는 이러한 디렉토리 중 하나의 역할을 맡을 수 없습니다. 즉, 이러한 디렉토리는 용도가 필요한 경우 사용되는 디렉토리 여야합니다.

다른 디렉토리는 루트에 나타나지 않아야합니다.

build/: 프로젝트 소스의 일부로 간주되지 않아야하는 특수 디렉토리입니다. 임시 빌드 결과를 저장하는 데 사용됩니다. 소스 제어에 체크인해서는 안됩니다. 소스 제어를 사용하는 경우 소스 제어 무시 목록을 사용하여 무시해야합니다.

src/: 주요 컴파일 가능한 소스 위치입니다. 하위 모듈을 사용하지 않는 컴파일 된 구성 요소가있는 프로젝트에 있어야합니다. 존재하에include/ 개인 헤더도 포함됩니다.

include/: 공개 헤더 용 디렉토리입니다. 존재할 수 있습니다. 개인 / 공개 헤더를 구분하지 않는 프로젝트의 경우 생략 할 수 있습니다. 하위 모듈을 사용하는 프로젝트의 경우 생략 할 수 있습니다.

tests/: 테스트 디렉토리입니다.

examples/: 샘플 및 예제를위한 디렉토리.

external/: 프로젝트에서 사용되지만 프로젝트의 일부로 편집되지 않는 패키지 / 프로젝트의 디렉토리입니다.

extras/: 프로젝트에 대한 추가 / 선택적 하위 모듈이 포함 된 디렉토리입니다.

data/: 프로젝트의 비 소스 코드 측면을 포함하는 디렉토리입니다. 여기에는 그래픽 및 마크 업 파일이 포함될 수 있습니다.

tools/: 빌드 및 리팩토링 스크립트와 같은 개발 유틸리티가 포함 된 디렉토리

docs/: 프로젝트 문서를위한 디렉토리.

libs/: 메인 프로젝트 서브 모듈을위한 디렉토리.

또한 extras/디렉토리는 Python 바인딩 이 이동해야하는 곳 이라고 생각합니다 .

실제로 이것에 대한 좋은 지침이 없다고 생각합니다. 대부분은 개인적인 취향 일뿐입니다. 하지만 특정 IDE는 기본 구조를 결정합니다. 예를 들어 Visual Studio는 Debug 및 Release 하위 폴더로 구분되는 별도의 bin 폴더를 만듭니다. VS에서 이것은 다른 대상을 사용하여 코드를 컴파일 할 때 의미가 있습니다. (디버그 모드, 릴리스 모드.)

greyfade가 말했듯이 자신에게 맞는 레이아웃을 사용하십시오. 다른 누군가가 그것을 좋아하지 않는다면, 그들은 그것을 스스로 재구성해야 할 것입니다. 다행히 대부분의 사용자는 선택한 구조에 만족할 것입니다. (정말 지저분하지 않는 한.)

나는 wxWidgets 라이브러리 (오픈 소스)가 좋은 예라고 생각합니다. 다양한 플랫폼 (Win32, Mac OS X, Linux, FreeBSD, Solaris, WinCE ...) 및 컴파일러 (MSVC, GCC, CodeWarrior, Watcom 등)를 지원합니다. 여기에서 트리 레이아웃을 볼 수 있습니다.

https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk/

CMake를 사용하는 것이 좋습니다. 플랫폼 간 개발을위한 것이며 automake가 훨씬 더 유연하고 CMake를 사용하며 모든 시스템에서 고유 한 디렉터리 구조로 교차 플랫폼 코드를 작성할 수 있습니다.