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

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를 선호합니다.)

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

---

실제로 이것에 대한 좋은 지침이 없다고 생각합니다. 대부분은 개인적인 취향 일뿐입니다. 하지만 특정 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/

---

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

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

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

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

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

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

include/: Directory for public headers. May be present. May be omitted for projects that do not distinguish between private/public headers. May be omitted for projects that use submodules.

tests/: Directory for tests.

examples/: Directory for samples and examples.

external/: Directory for packages/projects to be used by the project, but not edited as part of the project.

extras/: Directory containing extra/optional submodules for the project.

data/: Directory containing non-source code aspects of the project. This might include graphics and markup files.

tools/: Directory containing development utilities, such as build and refactoring scripts

docs/: Directory for project documentation.

libs/: Directory for main project submodules.

Additionally, I think the extras/ directory is where your Python bindings should go.

---

I can realy recommend you using CMake... it's for cross platform development and it's much more flexible that automake, use CMake and you will be able to write cross platform code with your own direcory structure on all systems.

참고URL : https://stackoverflow.com/questions/1398445/directory-structure-for-a-c-library