Cách tốt nhất để chia sẻ các tệp nguồn Delphi giữa các dự án là gì?

Question

Cách tốt nhất để chia sẻ tệp nguồn Delphi giữa các dự án là gì?

Làm rõ: Chúng tôi muốn sử dụng một tệp nguồn duy nhất trong nhiều dự án Delphi. Chúng tôi đã sử dụng công cụ SCM của chúng tôi để đặt cùng một tệp vào nhiều thư mục, nhưng đây không phải là trải nghiệm siêu thanh lịch và chúng tôi cũng đang cân nhắc việc chuyển sang công cụ không hỗ trợ điều này.

Khi tôi đang điều tra câu hỏi này, tôi đã xem xét một vài cách tiếp cận khác nhau, nhưng tôi muốn biết bạn đang làm gì và cách bạn tìm cách tiếp cận của mình.

kịch bản quan trọng:

• Mã thời gian
  • Thêm một sự phụ thuộc chia sẻ mới nên yêu cầu tuyên bố rõ ràng, vì vậy chia sẻ được quản lý.
  • Việc thêm phụ thuộc chia sẻ mới sẽ vẫn tương đối đơn giản; nó không nên đòi hỏi một quá trình phức tạp.
    • Một tệp liệt kê tất cả các tệp "đã nhập" của dự án (từ bên ngoài) sẽ đẹp.
• Compile-time
  • Tất cả các dự án phải luôn luôn xây dựng với một trong những phiên bản hiện tại (hiện tại như tình trạng nguồn đồng bộ cộng với chỉnh sửa địa phương).
    • (Duy trì các phiên bản khác nhau tại các địa điểm khác nhau nên sử dụng tập tin phân nhánh, mà không phải là chủ đề, ở đây.)
  • Dù từng dự án nên có thể ảnh hưởng đến biên soạn các tập tin chia sẻ với các thiết lập trình biên dịch khác nhau (bao gồm cả cờ) là đáng tranh cãi.
    • Có thể dễ dàng bảo trì mã nguồn (tức là lâu dài) luôn được xây dựng một cách nhất quán.
    • Có thể dễ dàng thực hiện các sửa chữa bảo trì (ví dụ: ngắn hạn) nếu phạm vi thay đổi nói trên có thể dễ dàng bị hạn chế đối với một dự án.
• Debug-thời gian
  • Các phiên bản đúng của nguồn sẽ tự động mở, khi bước vào một thói quen hoặc thiết lập một breakpoint.
  • Chỉnh sửa nguồn được hiển thị sẽ ảnh hưởng đến bản dựng tiếp theo.
    • Chúng tôi không muốn gỡ lỗi đối với bản sao tạm thời của nguồn: có thể chúng tôi sẽ mất mã, trong sự nhầm lẫn.

Lưu ý:

• Gần-Term:
  • cách tiếp cận nào sẽ được đơn giản nhất để đưa ra?
• Long-Term:
  • cách tiếp cận sẽ là gì đơn giản nhất để sử dụng và duy trì?

Cảm ơn, trước, cho phản hồi của bạn!

Mattias

---

--- Cập nhật ---

Cảm ơn phản hồi của bạn, qua câu trả lời, nhận xét và phiếu!

Tôi đã bắt đầu xuống đường dẫn đưa tệp được chia sẻ vào một dự án "nhà sản xuất" và nhập danh sách các tệp được biên dịch vào từng dự án "người tiêu dùng". Các dự án đang được liên kết với nhau với MSBuild. Khi mọi thứ được đóng đinh nhiều hơn, tôi sẽ chỉnh sửa câu hỏi này và câu trả lời "Dự án Thư viện" để chia sẻ những gì tôi đã học được.

Hãy chú ý theo dõi! (Nhưng đừng nín thở, bạn sẽ ngộp thở trong vòng vài phút: P)

Answer 1

Sử dụng Nguồn Tính năng File Sharing của hệ thống kiểm soát

• Pro: Nhanh chóng và dễ dàng để thiết lập, nếu SCM hệ thống hỗ trợ nó.
• Pro/Con: Mỗi dự án của người tiêu dùng có thể ảnh hưởng độc lập đến thời gian biên dịch.
• Con: Không có vị trí chính thức, trong bản sao nguồn làm việc tại địa phương.
  • Điều này có thể dẫn đến nhầm lẫn.
• Con: Thay đổi nguồn không được phản ánh ở các vị trí khác cho đến khi đăng ký và truy xuất lại.
  • Để xác minh chính xác các dự án khác, trước khi đăng ký, có thể xảy ra nhưng đau hoàng gia ở mông.
• Con: Không phải tất cả hệ thống SCM đều hỗ trợ tệp được chia sẻ.
  • Tính năng gần nhất của Subversion là svn: externals cấp thư mục.

(Chỉnh sửa: Đặt tiêu đề này để tránh nhầm lẫn.Tất nhiên, mọi người nên sử dụng Kiểm soát nguồn! :-))

Answer 2

Copy-on-biên dịch

• Pro: Chia sẻ tập tin có thể được quản lý file-by-file.
• Pro/Con: Mỗi dự án của người tiêu dùng có thể ảnh hưởng độc lập đến thời gian biên dịch.
• Con: Trình gỡ lỗi sẽ liên kết đến bản sao tạm thời, không phải phiên bản chính thức.
  • VIỆC LÀM: Xem có cách nào để thay đổi điều này không.
• Con: Có thể mất một số công việc để thiết lập dự án MSBuild.
• Con: Có thể khó xây dựng từng tệp được chia sẻ.
  • Có thể liên quan đến việc viết lại một số quy tắc MSBuild của Delphi.

Answer 3

Copy-Compile-Delete

• Pro: Chỉ có một bản sao chính thức của mỗi tập tin, chỉnh sửa.
• Pro: Trình gỡ lỗi sẽ không liên kết với bản sao tạm thời vì nó đã bị xóa bởi thời gian gỡ lỗi.
  • TODO: Xác minh rằng trình gỡ lỗi sẽ tìm nguồn gốc, nếu chúng tôi đặt nó trong “Đường dẫn duyệt web”.
• Pro: Chia sẻ tệp có thể được quản lý theo từng tệp.
• Pro/Con: Mỗi dự án của người tiêu dùng có thể ảnh hưởng độc lập đến thời gian biên dịch.
• Con: Có thể mất một số công việc để thiết lập các dự án MSBuild.
• Con: Có thể khó khăn/không thể tăng dần tệp được chia sẻ.
  • Có thể liên quan đến việc viết lại một số quy tắc MSBuild của Delphi.

Answer 4

Sử dụng một Dự án Thư viện

• Pro: Chỉ bao giờ một bản sao của mỗi tập tin vào khả năng chỉnh sửa.
• Pro: Chỉ một biên dịch, cho mỗi tệp nguồn.
  • Ít thời gian hơn để biên dịch.
  • Biên soạn nhất quán giữa các dự án phụ thuộc.
  • Xây dựng gia tăng tự nhiên.
• Pro: Trình gỡ lỗi tự nhiên liên kết đến nguồn thích hợp.
  • VIỆC LÀM: Xác nhận.
• Pro/Con: Dự án tiêu dùng không thể ảnh hưởng độc lập đến thời gian biên dịch.
• Con: Có thể khó quản lý việc chia sẻ ở cấp độ tệp theo tệp.
  • TODO: Điều tra.
• Con: Có thể nỗ lực đáng kể để thiết lập.
  • Thiết lập dự án MSBuild.
  • Cài đặt dự án bắt buộc phải được tập trung và những thay đổi này phải được xác minh.

Answer 5

Tôi nghĩ không có giải pháp đặc biệt nào được yêu cầu. Trong dự án của chúng tôi (một số ứng dụng chia sẻ các khu vực mã lớn), chúng tôi sử dụng phương pháp sau:

1. Tách mã nguồn thành các thư mục.
2. Tạo gói cho các đơn vị lôgic được chia sẻ hợp lý.
3. Hỗ trợ nguyên khối (không sử dụng gói) và xây dựng được chia nhỏ.
4. Xây dựng nguyên khối được sử dụng để mã hóa và gỡ lỗi. Mỗi ứng dụng có thư mục đầu ra Đơn vị riêng của nó, vì vậy tất cả chúng đều được xây dựng độc lập.
5. Hạn chế phụ thuộc được thực thi bởi đường dẫn tìm kiếm của dự án.
6. Xây dựng một phần được tạo tự động (chúng tôi sử dụng máy chủ CruiseControl và dự án MSBuild). Tự động xây dựng xóa tất cả các thư mục tạm thời trước khi xây dựng, do đó, không có sự phụ thuộc giữa các bản dựng liên tiếp.

Trong trường hợp của chúng tôi, chúng tôi không thể kiểm soát danh sách tệp đã nhập. Tuy nhiên, chúng tôi có thể kiểm soát danh sách các gói được nhập trong các bản dựng được chia nhỏ. Các gói nhỏ hơn có nghĩa là chi tiết hơn. Nếu ai đó đang thêm phụ thuộc vào đơn vị, nằm trong thư mục không có sẵn trong đường dẫn tìm kiếm và gói chứa đơn vị này không có trong danh sách sử dụng, thì việc tạo phân vùng không thành công. Vì vậy, hành động rõ ràng (sửa đổi kịch bản MSBuild tạo các tệp CFG để xây dựng một phần) là bắt buộc để thêm phụ thuộc.

P.S. Chúng tôi sử dụng các gói không để kiểm soát các phụ thuộc, nhưng vì các vấn đề không phải là phiên bản Windows NT chạy các ứng dụng lớn. Vì vậy, kiểm soát sự phụ thuộc là một tác dụng phụ. Các bản dựng được chia nhỏ được coi là "phát hành", và nguyên khối - là cấu hình "gỡ lỗi". Các ứng dụng Monolith chỉ được sử dụng để mã hóa và gỡ lỗi. Các nhà phát triển làm việc với các ứng dụng nguyên khối và giới thiệu các thay đổi của riêng họ đối với các cấu hình dự án như đính kèm thông tin gỡ lỗi VCL, bật và tắt các lỗi kiểm tra phạm vi, tối ưu hóa. Tuy nhiên, sau khi cam kết với SVN, CC sẽ cố gắng tạo một phần. Nó bỏ qua các tệp CFG từ kho lưu trữ và tái tạo chúng bằng cách sử dụng nhiệm vụ đặc biệt của dự án MSBuild. Vì vậy, chúng tôi có thể chắc chắn không có vấn đề với phụ thuộc đã được giới thiệu (và thực hiện kiểm tra khác là tốt).

Theo như chúng tôi không cần xây dựng nguyên khối và parted đồng thời, chúng tôi chỉ có một dự án duy nhất cho mỗi ứng dụng. Nếu bạn muốn xây dựng cả hai phiên bản trong kịch bản MSBuild, bạn có thể chỉ cần thêm một mục tiêu nữa, tạo lại CFG một lần nữa và chỉ định thêm một thư mục đầu ra Đơn vị. Đương nhiên, nếu cả hai phiên bản được yêu cầu cho các nhà phát triển, nó sẽ là thuận tiện hơn để có nhiều dự án hơn.

Answer 6

Tôi không chắc liệu mình có hiểu đúng câu hỏi hay không. Dù sao, khi xây dựng phần mềm ứng dụng (một số dự án nhưng nhiều mã phổ biến), chúng tôi tạo cấu trúc thư mục như thế này:

\Main 
    \Project1 
    \Project2 
    ... 
    \CommonUnits 

Chúng tôi thêm các đơn vị phổ biến với các dự án có liên quan (không phân biệt nó không phải trong cùng một folder với tài liệu dự án). Hơn nữa, đôi khi việc sử dụng định nghĩa có điều kiện ở cấp dự án dễ dàng hơn (Dự án | Tùy chọn | Thư mục/Điều kiện) để có sự khác biệt về mã nhỏ. Ví dụ, Project1 sẽ có một cái gì đó như "APP_PROJECT1" được xác định và sau đó bạn có thể sử dụng $ IFDEF trong các đơn vị chung để viết mã cụ thể.

Điều quan trọng: trong trường hợp này, tốt hơn nên có một kho lưu trữ kiểm soát nguồn cho toàn bộ bộ (gốc là \ Chính, tất nhiên).