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

C++ 라이브러리에서 작업 중입니다. 궁극적으로 몇 가지 예제와 Python 바인딩과 함께 여러 플랫폼 (Linux 및 Windows 이상)에서 공개적으로 사용할 수 있도록하고 싶습니다. 작업은 멋지게 진행되고 있지만 현재 프로젝트는 완전히 복잡하지 않고 Visual C++에 대해서만 만들어지며 멀티 플랫폼이 아닙니다.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 
    ...

나는 멀티 플랫폼 개발/오픈 소스 프로젝트에 더/작은 이전의 경험이없는 내가 찾을 수없는 매우 놀랐다 그러한 프로젝트를 구조화하는 방법에 관한 좋은 지침.

일반적으로 이러한 라이브러리 프로젝트를 어떻게 구성해야합니까? 읽을만한 것은 무엇입니까? 좋은 예가 있습니까? 유닉스 라이브러리들 사이에서 아주 흔한 일

출처

2009-09-09 TC.

이 OUT- CMake를 사용하는 경우 http://stackoverflow.com/questions/1383174/source-file-organisation/1383188#1383188 –

한 것은 그들이 있도록 구성되어 있다는 점이다 : 그것은 다소 /usr에서 전통적인 유닉스 파일 시스템을 반영

./   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`

여기서 물론

/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의 기본 설치 접두사)으로 끝나며,이 구조체를 전혀 준수하지 않을 수 있습니다.

어렵고 빠른 규칙이 없습니다. 나는 개인적으로 이런 방식으로 조직하지 않는다. (I 예를 들어, 모든 최대 규모의 프로젝트를 제외 ./src/ 디렉토리를 사용하지 마십시오. 내가 대신 CMake를 선호 autotools를 사용하지 않습니다.)

당신에게 나의 제안은 당신이 디렉토리 레이아웃을 선택해야한다는 것입니다

그 만든다 너에게 (및 너의 팀) 감각. 선택한 개발 환경, 빌드 도구 및 소스 제어에서 가장 현명한 작업을 수행하십시오.

출처

2009-09-09 09:41:05 greyfade

의 중복처럼 보인다 : 현재 트리 레이아웃을 볼 수 있습니다 of-source 빌드는 훌륭하게 보인다. – Korchkidu

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

greyfade가 말한 것처럼 나에게 맞는 레이아웃을 사용하십시오. 다른 사람이 그것을 좋아하지 않는다면, 그들은 단지 스스로 구조 조정을해야 할 것입니다. 다행히도 대부분의 사용자는 선택한 구조에 만족할 것입니다. (진짜 지저분한 게 아니라면)

출처

2009-09-09 10:07:05

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

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

출처

2009-09-09 10:27:25

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

답변

관련 문제