Tôi sắp mở một dự án C++ trên Sourceforge. Tôi có thể nhận một số mẹo về tổ chức mã không?

Question

Tôi sắp tải lên một dự án tôi đang làm việc trên Sourceforge theo GPL và hy vọng sẽ nhận được một số lời khuyên về cách tổ chức mã theo cách dễ hiểu và dễ sử dụng bởi bất kỳ nhà phát triển nào có thể nhìn vào nó, hoạt động tốt với git, và cách Sourceforge trình bày mọi thứ.

dự án của tôi là một ứng dụng C++ cross-platform, và bao gồm các nội dung sau:

• Một phần thư viện, mà hiện các công việc thực tế
• Một phần GUI riêng biệt, trong đó sử dụng các phần thư viện
• Thư viện nguồn mở, có chứa đường dẫn cần thiết để biên dịch thư viện
• Thư viện nguồn mở đã sửa đổi, và đã được thay đổi, và do đó có nghĩa là một phần trực tiếp của dự án này là
• Kết quả biên dịch của tất cả các thư viện

Cách tốt nhất để tổ chức này là gì?

Trong khi làm việc trên đó bản thân mình, từ gốc dự án Tôi có nó như thế này:
/LibPortion
/GuiPortion
/libs/thư viện nguồn mở
thư viện /libs/sửa đổi mã nguồn mở
/libs/biên dịch/để giữ các thư viện đã biên dịch, bao gồm khi biên dịch cho Windows một số thư viện không phải từ thư viện nguồn mở, chẳng hạn như các tệp thư viện Cygwin

Đây có phải là cách hợp lý để tổ chức mọi thứ không? Điều đó có phù hợp với quy ước và kỳ vọng không?

Khi kiểm tra trong dự án của tôi, bạn có nên kiểm tra trong thư viện nguồn mở cũng như một phần của dự án không? Tôi thấy rằng nó làm cho tinh thần để làm như vậy, bởi vì điều đó giảm thiểu ma sát với việc thiết lập dự án và chạy cho một dev mới. Chắc chắn tôi nên ít nhất là kiểm tra trong thư viện mã nguồn mở đã sửa đổi.

Ngoài ra, có ý nghĩa gì khi đưa vào kho lưu trữ trong thư viện được biên dịch? Tôi nghĩ rằng tốt nhất nên nói với git bỏ qua thư mục đó và để trống nó, vì nội dung của nó sẽ khác nhau trên mọi mục tiêu xây dựng, vì dự án của tôi là nền tảng chéo. Tuy nhiên, nó cũng có vẻ thực sự tốt cho những người không muốn gặp rắc rối với việc xây dựng và/hoặc tải xuống tất cả các thư viện để cung cấp các thư viện được biên dịch trước cho các nền tảng chính. Cách thông minh nhất để chia sẻ chúng là gì? Tôi đang nhìn vào Sourceforge, và nó không dễ dàng cho tôi biết cách tôi nên chia sẻ những thứ đó nếu không phải là một phần của kho lưu trữ git của tôi.

Answer 1

Nói chung, hãy tách biệt công việc của bạn khỏi tác phẩm của bên thứ ba. Ở cấp cơ bản nhất, thư mục gốc của bạn có thể trông giống như:

|- GUI 
|- Library 
|- Third-party 
    |- lib 
    |- source 

Tôi đã tách thư mục "bên thứ ba" thành hai thư mục con cho mục đích tuân thủ giấy phép và dễ sử dụng. Làm thế nào chính xác bạn phân phối libs bên thứ ba sẽ phụ thuộc hoàn toàn vào giấy phép của họ. Thiết lập các tệp makefiles của bạn để các thư viện được biên dịch sẽ nằm trong thư mục third-party\lib (đây cũng là nơi bạn cũng sẽ đặt bất kỳ thư viện nào được biên dịch trước). Bằng cách đó, người dùng có thể tải xuống các thư viện đã biên dịch trước và bỏ qua thư mục source hoặc tải xuống mã nguồn và bỏ qua thư mục lib tùy thuộc vào việc họ có muốn xây dựng lại libs của bên thứ ba hay không.

Nếu bạn được yêu cầu phân phối phiên bản đã sửa đổi của bạn ở dạng nhị phân và mã nguồn, thì bạn sẽ cần lưu trữ phiên bản đã sửa đổi trong kho lưu trữ nguồn của mình (cung cấp lib được biên dịch trước là lựa chọn của bạn).

Nếu bạn đang sử dụng thư viện chưa sửa đổi và đang sử dụng kho lưu trữ Subversion (hoặc tương tự), bạn có thể sử dụng thuộc tính externals để liên kết kho lưu trữ của bạn với kho lưu trữ của thư viện của bên thứ ba sao cho khi người dùng nhận được bản sao nguồn của bạn mã, nó lấy nguồn của lib từ repo riêng của nó. Bằng cách đó, bạn không cần phải giữ một tấm gương địa phương của nguồn thư viện. Tùy thuộc vào những gì mà bên thứ ba có sẵn trong repo của nó, bạn có thể sử dụng các phần tử bên ngoài để liên kết đến một phiên bản biên dịch trước của thư viện của bên thứ ba. Điều này sẽ không chỉ làm giảm số lượng mã mà bạn sẽ phải lưu trữ trong repo của bạn, nhưng nó cũng sẽ chỉ rõ ràng hơn rằng lib của bên thứ ba cụ thể chưa được sửa đổi.

Khi sử dụng thư viện chưa sửa đổi, sẽ tốt hơn nếu bạn không bao gồm nguồn hoặc nhị phân trong cây nguồn của mình. Chỉ cần ghi chú trong tài liệu của bạn rằng dự án của bạn phụ thuộc vào thư viện X (cũng chỉ định phiên bản, nếu nó quan trọng) và cung cấp liên kết đến trang chủ/thư mục/trang lưu trữ Sourceforge của thư viện đó. Hãy để nhà phát triển quyết định xem họ có muốn biên dịch thư viện hay không, tải xuống phiên bản được biên dịch trước hoặc có thể sử dụng phiên bản mà họ đã cài đặt. Điều này có nghĩa rằng bạn cũng không thể giả định rằng thư viện hoặc tiêu đề của thư viện sẽ tồn tại trong một thư mục cụ thể có liên quan đến mã nguồn của bạn; thay vào đó, bạn sẽ phải tin tưởng người dùng cài đặt các thư viện nơi trình biên dịch có thể tìm thấy chúng. Mã của bạn sẽ chỉ đơn giản giả định rằng chúng nằm trong đường dẫn tìm kiếm của trình biên dịch. Cũng có thể thư viện đã sửa đổi của bạn được triển khai sao cho tài sản bên ngoài sẽ khiến nguồn không được sửa đổi được lấy từ repo của bên thứ ba và hệ thống xây dựng của bạn có thể áp dụng bản vá chứa các sửa đổi của bạn. Bằng cách này, bạn sẽ không phân phối kỹ thuật mã đã sửa đổi, điều này có thể có nghĩa là bạn phải tuân theo một số điều khoản cấp phép ít hơn.

Thông thường, tôi sẽ không khuyên bạn nên phân phối các phiên bản biên dịch trước của thư viện của bạn bên trong kho lưu trữ nguồn của bạn. Với Sourceforge, bạn có thể biên dịch trước thư viện của mình (hoặc bất kỳ "sản phẩm cuối cùng" nào khác) cho các nền tảng chính và cung cấp chúng dưới dạng tải xuống.

Answer 2

Nếu tôi là bạn, trước tiên tôi sẽ tách riêng dự án giữa bạn và các thư viện của bên thứ ba. Cây sau đây có thể làm việc:

/ 
|- GUI 
|- lib 
|- third parties 
    |- compiled targets 
    |- "your first library" 
    |- "another library" 
    |- ... 

Bạn nên không lưu trữ thư viện biên soạn trên IMHO kho của bạn. Nó linh hoạt hơn để cho các nhà phát triển biên dịch chúng trên máy tính của riêng họ, nhưng nếu bạn muốn có một tarball có thể phân phối, nó sẽ bao gồm các thư viện biên dịch trước.

Answer 3

/
|- bin - Compiled binaries go here (not submitted to source-control) 
|- build - buildscripts, tools used to build your code. 
|- lib - Compiled libraries go here (not submitted to source-control) 
|- local - (not submitted to source control) 
    |- obj - Compiled object-files (not submitted to source-control) 
    |- msvc - Autogenerated solution files for visual studio (not submitted to source control) (if applicable) 
    |- scripts - Autogenerated script files (if applicable) 
|- units 
    |- libportion 
     |- include - external headers for other units to see 
     |- src 
    |- guiportion 
     |- include 
     |- src 
|- external 
    |- externallib1 
     |- include 
     |- src 

build - simplified build-script calling the correct convention to your buildscripts. 
README - text-file explaining your software and the layout of your source. 

Đây là tổ chức mà tôi đã sử dụng gần đây và nó được đánh giá rất cao bởi mọi người được bao gồm. Nó cũng làm cho nó dễ dàng để tách các thư viện giữa mỗi người khác và làm cho nó dễ dàng để cung cấp các tiêu đề nội bộ và các tiêu đề bên ngoài trong thư viện.

Chỉnh sửa: Đã thêm thư mục "cục bộ".

Answer 4

IMHO xem xét việc tổ chức các dự án nguồn mở khác nhau có thể hữu ích.

vlc project page có thể là một tài liệu tham khảo tốt