C ++ 크로스 플랫폼 라이브러리 및 바인딩을위한 최상의 폴더 구조
C ++로 작성 될 크로스 플랫폼 라이브러리 작업을 시작하려고합니다. 앞으로 저는 Python, Java 등과 같은 다른 언어에 대한 바인딩을 구현할 계획입니다. 라이브러리는 win32, Linux 및 Mac OSX와 같은 주요 플랫폼에서 사용할 수 있어야합니다.
응용 프로그램은 실제로 라이브러리이지만 데모 및 테스트를 위해 일부 기본 콘솔 프로그램이 함께 번들로 제공됩니다.
Subversion에 물건을 저장하기 전에 최적의 폴더 구조를 찾고 싶습니다.
나는 다음과 같은 것을 생각하고 있습니다.
/project //Top level folder
/bin //Binaries ready for deployment
/linux_amd64 //Linux AMD64 platform
/debug //Debug build - duplicated in all platforms
/release //Release build - duplicated in all platforms
/linux_i386 //Linux 32-bit platform
/macosx //Mac OS X
/win32 //Windows 32-bit platform
/cygwin //Windows 32-bit platform compiled with Cygwin
/vs.net //Windows 32-bit platform compiled with Visual Studio .NET
/win64 //Windows 64-bit platform
/build //Make and build files, IDE project files
/linux_amd64 //Linux AMD64 platform
/linux_i386 //Linux 32-bit platform
/macosx //Mac OS X
/win32 //Windows 32-bit platform
/win64 //Windows 64-bit platform
/config //Configuration files that accompany the binaries
/data //Data files that accompany the binaries
/doc //Documentation
/lib //External or third-party libraries
/platforms //Platform-specific code for ...
/linux_amd64 //Linux AMD64 platform
/linux_i386 //Linux 32-bit platform
/macosx //Mac OS X
/win32 //Windows 32-bit platform
/win64 //Windows 64-bit platform
/src //Available library source code in subfolders
/src //Source code tree - this will contain main.cpp
/bindings //Bindings to other languages such as ...
/python
/java
/h //Header files
/modules //Platform-independent modules, components or subprojects
/platforms //Platform-specific code for ...
/linux_amd64 //Linux AMD64 platform-specific code
/linux_i386 //Linux 32-bit platform-specific code
/macosx
/win32 //Windows 32-bit platform-specific code
/win64 //Windows 64-bit platform
/test //Automated test scripts
제안 사항이 있으면 듣고 싶습니다. 이 구조를 만드는 데 도움이되는 도구가 있는지 궁금합니다.
CMake와 Subversion을 사용할 계획입니다.
구조는 나에게 좋게 보이지만 몇 가지 요점이 있습니다.
- C ++ 헤더와 소스 파일을 다른 디렉토리로 분리하는 것이 정상입니까? 아니면 표시하지 않는 모듈 디렉토리에 구조가 있습니까?
- * .obj와 같은 중간 파일을 디렉토리에 넣기를 원할 것입니다.
- 디버그 및 릴리스 출력 파일에 대해 다른 디렉토리가 필요합니다.
- InnoSetup 및 설치 파일과 같은 설치 프로그램을위한 디렉토리가 유용 할 수 있습니다. 버전 제어 여부에 대한 철학적 결정을 내려야합니다.
구조를 만드는 도구는 bash 스크립트를 작성하는 데 몇 분이면 충분합니다. 모든 플랫폼에서 동일한 도구 (예 : bash)를 사용할 수있는 것이 좋습니다.
바이너리 파일에 대해 다른 플랫폼 폴더가 필요한 이유는 무엇입니까? 이 소스 코드를 서로 다른 플랫폼에서 빌드하지만 동일한 파일 시스템을 사용 하시겠습니까?
그렇다면 컴파일러 특정 폴더도 필요하다고 생각합니다.
디버그 및 릴리스 빌드에 다른 폴더를 사용하지 않는 이유는 무엇입니까? 유니 코드 및 비 유니 코드, 단일 스레딩 또는 다중 스레딩 빌드 일 수 있습니다.
bjam 또는 Scons make replacers를보십시오. 빌드 디렉토리에 다른 폴더가 필요하지 않을 수도 있습니다.
"modules"디렉토리의 모든 모듈이 테스트 자체를위한 "tests"디렉토리를 포함한다면 더 좋을 것 같습니다.
마지막으로 부스트 라이브러리를 참조하십시오.이 platofrm 독립 라이브러리는 멋진 구조를 가지고 있습니다.
또한 다른 플랫폼 독립 프로젝트에서 아이디어를 얻으십시오.
폴더 구조 향상 :
boost - root dir
- boost - library header lib ( for users )
- libs - library source dir ( one dir per lib )
- build - library build files ( if they are needed )
- doc - documentation files
- example - sample programs
- src - library source files
- test - programs and srcipts for testing module
- bin - created by bjam build system
- libs
- <lib-name>
for all compiled folders from libs [example|test|build]
- <compiler-name>/<[static|dynamic]-link>/<[debug|release]>/<[threading mode]>
contain builded [obj|dll|lib|pdb|so|o|etc] files see detailed information in bjam build system
- doc
- tools
bjam을 선택하면 빌드 및 빈 폴더 구조에 관심이 없습니다.
또한 libs / src / dir에는 모든 플랫폼 파일에 대한 자체 및 플랫폼 특정 파일에 대한 몇 개의 디렉터리가 포함될 수 있습니다.
I don't see any serious problems in your folders structre, maybe you will see them when start write project prototype.
I recently posted a question about packaging headers in just one directory, decided to go with a small number of include directories.
Are you going to cater for Win64? That will be an increasingly important target.
Do not put your build intermediate files anywhere under a tree being checked into svn. If you do so, depending on your svn client tools, they will generate a lot of noise as files which are not in the repository. That makes it hard to see files you've added that should be in the repository.
Instead, if your compiler allows it, put the intermediate directories off to one side.
Otherwise, make sure you add the entire intermediate directories to your svn exclusion properties. Some GUI's make that easier than others (Tortoise on Windows, Cornerstone or Versions on OS/X).
Might I suggest not using the architecture to categorize build files?
I was trying to apply your proposed folder structure but I couldn't find the correct place to put common Linux Makefile definitions and Visual Studio property files. How about just the following:
/project
/build
/linux
/macosx
/win32 (or win)
And example case would include:
/project
/build
/linux
Make.defs
Makefile [i386, amd64]
/win32
/VC8
/<project>
<project>.vcproj
<solution>.sln [Win32, x64]
/VC11
/<project>
<project>.vcxproj
<solution>.sln [Win32, x64, ARM]
If you don't want to define architecture builds through configurations, how about another folder layer under the platform types?
/project
/build
/linux
/linux_amd64
/linux_i386
/macosx
/?
/win32 (or win)
/win32
/win64
If a given project will not have any common build files for a platform, the original structure would suffice.
ReferenceURL : https://stackoverflow.com/questions/718126/best-folder-structure-for-c-cross-platform-library-and-bindings
'programing' 카테고리의 다른 글
| react.js-어떤 확장자를 사용할까요- '.jsx'또는 '.js'? (0) | 2021.01.16 |
|---|---|
| 초기화에 lvalue에서 rvalue로 변환이 수반됩니까? (0) | 2021.01.16 |
| Tomcat에서 배포 해제 메모리 누수를 피할 수있는 방법이 있습니까? (0) | 2021.01.16 |
| C에서 반환 값 최적화 및 복사 제거 (0) | 2021.01.15 |
| WinForms C #의 우아한 로그 창 (0) | 2021.01.15 |