2009-04-05 37 views
51

Tôi sắp bắt đầu làm việc trên một thư viện đa nền tảng được viết bằng C++. Xuống đường, tôi dự định triển khai các ràng buộc cho các ngôn ngữ khác như Python, Java, vv Thư viện cần có sẵn trên các nền tảng chính: win32, Linux và Mac OSX.Cấu trúc thư mục tốt nhất cho thư viện đa nền tảng C++ và các ràng buộc

Mặc dù ứng dụng thực sự là một thư viện, một số chương trình điều khiển cơ bản sẽ được nhóm cùng với nó để trình diễn và thử nghiệm.

Tôi muốn tìm ra cấu trúc thư mục tối ưu trước khi tôi bắt đầu lưu trữ nội dung trong Subversion.

Tôi đang nghĩ đến một cái gì đó như:

/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 

Nếu bạn có gợi ý, tôi muốn nghe họ. Tôi tự hỏi nếu có một công cụ có thể giúp tạo ra cấu trúc này.

Tôi đang lên kế hoạch sử dụng CMake và Subversion.

+0

Tôi có một câu hỏi cho bạn: vì nó là một lib, main.cpp là gì và làm thế nào điều này sẽ được sử dụng bởi người khác? Tôi đang đối mặt với câu hỏi ATM, và tôi nghĩ main.cpp thực sự là một thử nghiệm của lib. Không phải nó? –

+1

Tôi có một câu trả lời liên quan ở đây: [Tốt nhất (sạch) cách để viết mã nền tảng cụ thể] (https://stackoverflow.com/a/32685299/3258851) –

Trả lời

6

Tại sao bạn cần thư mục nền tảng khác nhau cho tệp nhị phân? Bạn sẽ xây dựng mã nguồn này theo các platoforms khác nhau nhưng với cùng một hệ thống tập tin?

Nếu có, tôi nghĩ bạn cũng cần các thư mục dành riêng cho trình biên dịch.

Tại sao bạn không sử dụng các thư mục khác nhau để gỡ lỗi và phát hành xây dựng, có thể unicode và không unicode, đơn luồng hoặc đa luồng xây dựng?

Nhìn vào bjam hoặc Scons tạo replacers. Có thể bạn không cần thư mục khác trong thư mục xây dựng.

Tôi nghĩ sẽ tốt hơn nếu tất cả các mô-đun từ thư mục "mô-đun" sẽ chứa thư mục "kiểm tra" để tự kiểm tra.


Và thư viện tăng cường cuối cùng, thư viện riêng biệt này có cấu trúc đẹp.

Cũng cố gắng lấy ý tưởng từ các dự án độc lập nền tảng khác.

Boost thư mục cấu trúc:

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 

Nếu bạn chọn bjam - bạn sẽ không được quan tâm về xây dựng và thư mục bin cấu trúc.

Cũng libs/src/dir của bạn có thể chứa riêng cho tất cả các tệp nền tảng và vài thư mục dành cho tệp nền tảng spcific.

Tôi không thấy bất kỳ vấn đề nghiêm trọng nào trong cấu trúc thư mục của bạn, có thể bạn sẽ thấy chúng khi bắt đầu viết mẫu thử nghiệm dự án.

+0

Tôi sẽ không thực hiện việc biên dịch chéo, tức là macosx phải là được xây dựng dựa trên macosx. Có các thư mục khác nhau để gỡ lỗi và phát hành là một ý tưởng hay. –

+0

Tôi đã xem xét tăng nhưng không thể dễ dàng biết cách họ đang quản lý nền tảng. Họ dường như đang sử dụng mứt tăng cường. –

+0

bjam (boost jam) có một đường cong học tập dốc, và là một ngôn ngữ ưa thích hơn sau đó bất cứ điều gì khác. Sẽ không giới thiệu nó. Thay thế tốt nhất để làm theo cách tôi đã tìm thấy là cào; chỉ vì nó linh hoạt, được sử dụng rộng rãi và khá dễ dàng để tìm hiểu và sử dụng. – srcspider

10

Cấu trúc có vẻ tốt với tôi, nhưng có một vài điểm:

  • đó là bình thường để tách C++ file header và nguồn vào thư mục khác nhau, hoặc có thể có cấu trúc trong thư mục modules bạn không hiển thị ?
  • có thể bạn muốn thư mục để đưa các file trung gian như * .obj trong
  • bạn sẽ cần thư mục khác nhau để gỡ lỗi và phát hành tập tin đầu ra
  • một thư mục cho các trình cài đặt như InnoSetup và họ cài đặt tập tin có thể có ích - bạn phải đưa ra quyết định về mặt triết học về việc liệu phiên bản có nên kiểm soát các số này

Đối với các công cụ để tạo cấu trúc, hãy dành vài phút để viết một tập lệnh bash là tất cả những gì bạn cần - nền tảng.

+0

Cảm ơn, tôi đã thêm một số đề xuất của bạn vào cây. –

2

Gần đây, tôi đã đăng một question about packaging headers chỉ trong một thư mục, đã quyết định đi kèm với một số lượng nhỏ thư mục bao gồm.

Bạn sẽ phục vụ cho Win64? Đó sẽ là mục tiêu ngày càng quan trọng.

Làm không đặt các tệp trung gian xây dựng của bạn ở bất kỳ đâu dưới gốc cây đang được kiểm tra vào svn. Nếu bạn làm như vậy, tùy thuộc vào công cụ khách hàng svn của bạn, họ sẽ tạo ra rất nhiều tiếng ồn là tệp không có trong kho lưu trữ. Điều đó khiến bạn khó thấy các tệp bạn đã thêm nên có trong kho lưu trữ.

Thay vào đó, nếu trình biên dịch của bạn cho phép, hãy đặt các thư mục trung gian sang một bên.

Nếu không, hãy đảm bảo bạn thêm toàn bộ thư mục trung gian vào thuộc tính loại trừ svn của mình. Một số GUI làm cho dễ dàng hơn những người khác (Rùa trên Windows, Nền tảng hoặc Phiên bản trên OS/X).

+0

Tôi đã không nghĩ đến win64 nhưng đã thêm nó vào danh sách. Cảm ơn! svn giúp bạn dễ dàng loại trừ các tệp trung gian như .o và .obj bằng thuộc tính svn-ignore trên thư mục chứa. –

0

Tôi có thể đề xuất không sử dụng kiến ​​trúc để phân loại tệp xây dựng không?

Tôi đã cố gắng áp dụng cấu trúc thư mục được đề xuất của bạn nhưng tôi không thể tìm thấy địa điểm chính xác để đặt các định nghĩa tệp Makefile và tệp thuộc tính Visual Studio phổ biến. Làm thế nào về chỉ sau:

/project 
    /build 
     /linux 
     /macosx 
     /win32 (or win) 

Và ví dụ trường hợp sẽ bao gồm:

/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] 

Nếu bạn không muốn xác định kiến ​​trúc được xây dựng thông qua các cấu hình, làm thế nào về một lớp thư mục theo các loại nền tảng?

/project 
    /build 
     /linux 
     /linux_amd64 
     /linux_i386 
     /macosx 
     /? 
     /win32 (or win) 
     /win32 
     /win64 

Nếu một dự án cụ thể sẽ không có bất kỳ tệp xây dựng phổ biến nào cho nền tảng, cấu trúc gốc sẽ đủ.

Các vấn đề liên quan