2009-02-27 66 views
6

Tôi có mã nguồn khoảng 500 tệp trong khoảng 10 thư mục. Tôi cần phải cấu trúc lại cấu trúc thư mục - điều này bao gồm việc thay đổi hệ thống phân cấp thư mục hoặc đổi tên một số thư mục.Tái cấu trúc thư mục C++

Tôi đang sử dụng kiểm soát phiên bản svn. Có hai cách để refactor: một trong những bảo tồn lịch sử svn (sử dụng lệnh di chuyển svn) và khác mà không cần bảo quản. Tôi nghĩ rằng việc tái cấu trúc bảo quản lịch sử svn dễ dàng hơn nhiều bằng cách sử dụng plugin Eclipse và SVN eclipse (studio trực quan không phù hợp với tất cả để tái cấu trúc thư mục).

Nhưng ngay bây giờ vì mã không được phát hành, chúng tôi có tùy chọn để không giữ lại lịch sử.

Vẫn còn nhiệm vụ thay đổi bao gồm các chỉ thị của tệp tiêu đề ở bất cứ đâu. Tôi đang nghĩ đến việc viết một kịch bản nhỏ bằng cách sử dụng python - nhận bản đồ từ tên tệp hiện tại đến tên tệp mới và thực hiện việc đổi tên ở bất cứ nơi nào cần thiết (sử dụng một cái gì đó như sed). Có ai đã thực hiện loại tái cấu trúc thư mục này không? Bạn có biết các công cụ liên quan tốt không?

+0

Hy vọng rằng codebase của bạn sử dụng đường dẫn dựa trên gốc của cây nguồn như #include "có thể/some/stuff.h" và không phải đường dẫn tương đối như #include "../../../stuff.h". – bk1e

+0

@ bk1e, đúng vậy. –

Trả lời

3

Nếu bạn phải viết lại #include để thực hiện việc này, bạn đã làm sai. Thay đổi tất cả #includes của bạn để sử dụng cấu trúc thư mục rất đơn giản, ở hai cấp độ sâu và chỉ sử dụng cấp độ thứ hai để sắp xếp kiến ​​trúc hoặc phụ thuộc hệ điều hành (như sys/types.h).

Sau đó, thay đổi tệp của bạn để sử dụng -I bao gồm đường dẫn.

Thì đấy. Bạn sẽ không bao giờ phải hack mã một lần nữa cho điều này, và biên dịch sẽ thổi lên ngay lập tức nếu có gì đó không ổn.

Theo như phần lịch sử, cá nhân tôi tìm thấy nó dễ dàng hơn để làm cho một khởi đầu sạch sẽ khi làm điều này loại điều; lưu trữ tệp cũ, tạo kho lưu trữ mới v2, chuyển từ đó. Các counterargument là khi có rất nhiều toàn bộ lịch sử thay đổi, hoặc rất nhiều các vấn đề mở đối với các mã hiện có.

Ồ, và bạn có các bài kiểm tra tốt, và bạn không làm điều này với bản phát hành sắp tới, phải không?

+0

Đồng ý - cấu trúc thuộc về thông tin xây dựng không phải mã. Các trình biên dịch Mac tất cả được sử dụng để cho phép bạn chỉ định một cây thư mục, do đó bạn không phải bận tâm với nhiều đường dẫn rõ ràng. Đó là một cú sốc khi tôi bắt đầu sử dụng Visual Studio! –

+0

"Sau đó, thay đổi tập tin của bạn để sử dụng -I bao gồm đường dẫn" - Bao gồm không nên quá sâu nhưng tôi sẽ không muốn phức tạp -I đường dẫn. Nên có trình bao bọc ở cấp cao nhất của mỗi thư mục cung cấp "mặt tiền" cho thư mục. Đây là cách Boost hoạt động; sử dụng nó chỉ cần bao gồm chỉ một thư mục. –

+0

Tôi không nghĩ rằng nó quá quan trọng theo cách bạn làm điều đó, nhưng các tập tin wrapper có nghĩa là bạn phải đọc mã để hiểu cách xây dựng hoạt động; Tôi muốn có thể tìm thấy mọi thứ trong Makefile. –

2

Tôi sẽ bảo tồn lịch sử, ngay cả khi mất thêm một lượng thời gian nhỏ. Có rất nhiều giá trị trong việc có thể đọc qua các nhật ký cam kết và hiểu tại sao hàm X được viết theo cách kỳ lạ, hoặc đây thực sự là một lỗi một bởi vì nó được viết bởi Oliver, người luôn luôn sai.

Các lập luận chống lại việc bảo tồn lịch sử có thể được thực hiện cho người dùng sau:

  • mã của bạn có thể có những điều đáng xấu hổ, giống như báng bổ và chữa cháy cho nhà phát triển
  • bạn không quan tâm về những cam kết lịch sử mã của bạn, bởi vì mã sẽ không thay đổi hoặc được duy trì trong tương lai

Tôi đã thực hiện một số phép tái cấu trúc thư mục như thế này vào năm ngoái trên cơ sở mã của chúng tôi. Nếu mã của bạn được cấu trúc hợp lý ngay từ đầu, bạn có thể làm khoảng 75-90% công việc bằng cách sử dụng các tập lệnh được viết bằng ngôn ngữ bạn chọn (tôi đã sử dụng Perl). Trong trường hợp của tôi, chúng tôi đã chuyển từ tập hợp các tập tin tất cả trong một thư mục lớn, đến một loạt các thư mục lồng nhau tùy thuộc vào không gian tên. Vì vậy, một tập tin khai báo các giao thức lớp :: serialization :: SerializerBase được đặt trong src/protocols/serialization/SerializerBase. Ánh xạ từ tên cũ đến tên mới là tầm thường, do đó việc tìm kiếm và thay thế trên #includes trong mọi tệp nguồn trong cây là tầm thường, mặc dù đó là một thay đổi lớn.Có một vài trường hợp cạnh kỳ lạ mà chúng tôi phải sửa bằng tay, nhưng điều đó có vẻ tốt hơn rất nhiều so với việc phải làm mọi thứ bằng tay hoặc phải viết trình phân tích cú pháp C++ của riêng chúng tôi.

2

Lấy cắp tập lệnh hệ vỏ để thực hiện các thao tác svn là không đáng kể. Trong tcsh nó là foreach F ($ FILES) ... kết thúc để điều chỉnh một tập hợp các tệp. Perl & Python cung cấp tiện ích tốt hơn.

Nó thực sự đáng để lưu lịch sử. Đặc biệt là khi cố gắng theo dõi một số lỗi kỳ lạ. Những ai không học hỏi từ lịch sử đang cam chịu để lặp lại nó, hoặc một số linh tinh như vậy ...

Đối với thay đổi tất cả các file ... Có một câu hỏi tương tự chỉ là ngày khác trên tại địa chỉ:

https://stackoverflow.com/questions/573430/ c-include-header-path-change-windows-to-linux/573531#573531