2012-06-15 25 views
9

Chúng tôi có thư viện Boost ở phía chúng tôi. Nó bao gồm một số lượng lớn các tập tin mà không bao giờ thay đổi và chỉ một phần nhỏ của nó được sử dụng. Chúng tôi trao đổi toàn bộ thư mục tăng nếu chúng tôi đang thay đổi phiên bản. Hiện tại chúng tôi có các nguồn Boost trong SVN của chúng tôi, tập tin theo tập tin mà làm cho các hoạt động thanh toán rất chậm, đặc biệt là trên Windows.g ++: Sử dụng tệp ZIP làm đầu vào

Nó sẽ được tốt đẹp nếu có một ký hiệu/plugin để giải quyết các file C++ bên trong các tập tin ZIP, một cái gì đó như:

// @ZIPFS ASSIGN 'boost' 'boost.zip/boost' 
#include <boost/smart_ptr/shared_ptr.hpp> 

Có bất kỳ sự hỗ trợ cho lưỡi câu biên dịch tính bằng g ++? Có bất kỳ nỗ lực nào liên quan đến hỗ trợ ZIP không? Những ý tưởng khác?

+0

Nếu bạn đang sử dụng 'g ++', tại sao không sử dụng' gzip' để khớp? Haha trò đùa xấu, +1. –

+6

Di chuyển khỏi SVN sang hệ thống SCM hiện đại? Hoặc bạn có thể nén thư mục tăng lên để đưa vào SVN để làm cho nó nhanh hơn để kiểm tra, và sau đó có một phần của quá trình xây dựng được giải nén tập tin đó nếu cần thiết. – bames53

+0

@ bames53 Nghĩ về nó. Nó sẽ không tiết kiệm nhiều thời gian trên các cửa sổ, vì việc khai thác nhiều tập tin nhỏ. Chắc chắn, nó sẽ tốt hơn một chút. – Notinlist

Trả lời

9

Tôi giả định rằng make hoặc một hệ thống xây dựng tương tự có liên quan đến quá trình xây dựng phần mềm của bạn. Tôi sẽ đặt tệp zip vào kho lưu trữ và thêm quy tắc vào Makefile để trích xuất tệp trước khi bắt đầu xây dựng thực tế. Ví dụ: giả sử tệp zip của bạn nằm trong cây nguồn ở "external/boost.zip" và nó sẽ được trích xuất thành "external/boost" và nó chứa tại tệp toplevel tệp "boost_version.h" của nó. .

# external/Makefile 
unpack_boost: boost/boost_version.h 

boost/boost_version.h: boost.zip 
    unzip $< 

Tôi không biết cú pháp chính xác của cuộc gọi unzip, hãy hỏi manpage của bạn về điều này.

Sau đó, trong các tệp Makefiles khác, bạn có thể cho phép tệp nguồn của bạn phụ thuộc vào mục tiêu unpack_boost để có được make giải nén Boost trước khi tệp nguồn được biên soạn.

# src/Makefile (excerpt) 
unpack_boost: 
    make -C ../external unpack_boost 

source_file.cpp: unpack_boost 

Nếu bạn đang sử dụng một máy phát điện Makefile (hoặc một buildsystem hoàn toàn khác nhau), hãy kiểm tra các tài liệu cho các chương trình này để biết cách tạo một cái gì đó như mục tiêu tùy chỉnh unpack_boost. Ví dụ, trong CMake, bạn có thể sử dụng chỉ thị add_custom_command.

Bản in đẹp: Tệp boost/boost_version.h không thực sự cần thiết để Makefile hoạt động. Bạn có thể chỉ cần đặt lệnh unzip vào mục tiêu unpack_boost, nhưng sau đó mục tiêu sẽ có hiệu quả là giả mạo, nghĩa là: nó sẽ được thực thi trong mỗi lần xây dựng. Các tập tin inbetween (mà tất nhiên bạn cần phải thay thế bởi một tập tin đó là thực sự hiện diện trong kho lưu trữ zip) đảm bảo rằng unzip chỉ chạy nếu cần thiết.

2

Đây là điều bạn sẽ không làm trong g ++, bởi vì bất kỳ ứng dụng nào khác muốn làm điều đó cũng sẽ phải được sửa đổi.

Lưu trữ tệp trên hệ thống tệp nén. Sau đó, mọi ứng dụng đều nhận được lợi ích tự động.

+0

Nếu g ++ không bị "nối" như vậy thì chú thích sẽ bị bỏ qua và zip có thể được trích xuất thủ công (như dự phòng). Boost không cần phải biết về tất cả điều này. Ngày thứ hai: hệ thống tập tin nén không tăng tốc độ thanh toán. – Notinlist

2

Có thể trong hệ điều hành để cho phép truy cập trong suốt vào tệp trong tệp ZIP. Tôi biết rằng tôi đặt nó trong thiết kế của hệ điều hành của riêng tôi một thời gian dài trước đây (năm 2004 hoặc lâu hơn) nhưng không bao giờ có nó đến một điểm mà nó có thể sử dụng được. Nhược điểm là tìm kiếm ngược trong một tập tin bên trong một ZIP là chậm hơn vì nó được nén (và bạn không thể tua lại trạng thái máy nén, vì vậy bạn phải tìm kiếm từ đầu thay vào đó). Điều này cũng làm cho việc sử dụng zip-inside-a-zip chậm để tua lại và đọc. May mắn thay, hầu hết các trường hợp chỉ đọc một tập tin tuần tự.

Nó cũng phải được trang bị lại cho hệ điều hành hiện tại, ít nhất là trong không gian của khách hàng. Bạn có thể móc các hàm truy cập hệ thống tập tin được sử dụng (fopen, open, ...) và thêm một bộ mô tả tệp ảo mà phần mềm của riêng bạn sẽ trả về cho một tên tệp đã cho.Nếu đó là một tập tin thực sự chỉ cần vượt qua nó trên, nếu nó không mở tập tin cơ bản (có thể một lần nữa thông qua chức năng này rất) và vượt qua một xử lý ảo. Khi truy cập nội dung tập tin, hãy đọc trực tiếp từ tệp zip mà không cần lưu vào bộ nhớ đệm. Trên Linux, bạn sẽ sử dụng LD_PRELOAD để tiêm nó vào phần mềm hiện có (tại thời điểm sử dụng), trên Windows, bạn có thể móc các cuộc gọi hệ thống hoặc tiêm một DLL vào không gian của phần mềm để móc các chức năng tương tự.

Có ai biết nếu điều này đã tồn tại? Tôi không thể thấy bất kỳ lý do rõ ràng nào mà nó sẽ không ...

+1

Trên LINUX có mô-đun hạt nhân FUSE (Hệ thống tập tin không gian người dùng E-bất cứ điều gì). –

4

Chúng tôi đang đối mặt với các vấn đề tương tự trong công ty của chúng tôi. Quản lý các phiên bản tăng cường trong môi trường xây dựng sẽ không bao giờ dễ dàng. Với hơn 10 nhà phát triển, tất cả mã hóa trên (các) hệ thống của riêng họ, bạn sẽ cần một số loại tự động hóa. Trước tiên, tôi không nghĩ rằng nên lưu trữ các bản sao của các thư viện lớn như tăng SVN hoặc bất kỳ hệ thống SCM nào cho vấn đề đó, đó không phải là những hệ thống được thiết kế, ngoại trừ nếu bạn định sửa đổi mã bản thân bạn. Nhưng hãy giả sử bạn không làm điều đó.

Dưới đây là cách chúng tôi quản lý ngay bây giờ, sau khi thử nhiều phương pháp khác nhau, điều này phù hợp nhất với chúng tôi.

Đối với mỗi phiên bản tăng cường mà chúng tôi sử dụng, chúng tôi đặt toàn bộ cây (giải nén) trên máy chủ tệp và thêm các thư mục phụ, một cho mỗi kiến ​​trúc/trình biên dịch kết hợp, nơi chúng tôi đặt các thư viện đã biên dịch. Chúng tôi giữ bản sao của những cây trên mọi hệ thống xây dựng và trong môi trường hệ thống toàn cầu, chúng tôi thêm các biến như:

BOOST_1_48=C:\boost\1.48 # Windows environment var 

hoặc

BOOST_1_48=/usr/local/boost/1.48 # Linux environment var, e.g. in /etc/profile.d/boost.sh 

Thư mục này chứa các cây tăng (. Boost/* hpp) và các lib được biên dịch trước (ví dụ: lib/win/x64/msvc2010/libboost_system * .lib, ...)

Tất cả các cấu hình xây dựng (so với các giải pháp, tập tin thuộc tính, gnu makefiles, ...) xác định biến nội bộ , nhập vars môi trường, như:

BOOSTROOT=$(BOOST_1_48) # e.g. in a Makefile, or an included Makefile 

và các quy tắc xây dựng tiếp theo đều sử dụng cài đặt BOOSTROOT để xác định đường dẫn tìm kiếm và thư viện, ví dụ:

CXXFLAGS += -I$(BOOSTROOT) 
LFLAGS += -L$(BOOSTROOT)/lib/linux/x64/ubuntu/precise 
LFLAGS += -lboost_date_time 

Lý do giữ bản sao cục bộ là tốc độ biên dịch. Nó chiếm khá nhiều không gian đĩa, đặc biệt là các thư viện biên dịch, nhưng dung lượng lưu trữ rẻ và một nhà phát triển mất rất nhiều thời gian biên dịch mã thì không. Ngoài ra, điều này chỉ cần được sao chép một lần.

Lý do sử dụng các môi trường toàn cầu là cấu hình xây dựng có thể chuyển từ hệ thống này sang hệ thống khác và do đó có thể được kiểm tra an toàn vào hệ thống SCM của bạn.

Để làm mịn mọi thứ một chút, chúng tôi đã phát triển một công cụ nhỏ để quản lý việc sao chép và thiết lập môi trường toàn cầu. Với một CLI, điều này thậm chí có thể được bao gồm trong quá trình xây dựng.

Môi trường làm việc khác nhau có nghĩa là các quy tắc và nền văn hóa khác nhau, nhưng hãy tin tôi, chúng tôi đã thử nhiều thứ và cuối cùng, chúng tôi quyết định xác định một số loại quy ước. Có thể chúng ta có thể truyền cảm hứng cho bạn ...

+0

Điều này tương tự như cách chúng tôi thực hiện, ngoại trừ việc chúng tôi tăng liên kết tượng trưng/lên một trong các phiên bản tăng cường khác nhau tồn tại. – KitsuneYMG

+0

Tốt, miễn là hệ thống tệp hỗ trợ các liên kết tượng trưng. Chúng tôi cần một phương thức hoạt động trên cả hệ thống Windows và * nix. – Pat

7

Một năm trước, tôi đã ở cùng vị trí với bạn.Chúng tôi giữ nguồn của chúng tôi trong SVN và, thậm chí tệ hơn, bao gồm tăng trong cùng một kho lưu trữ (cùng một chi nhánh) như mã riêng của chúng tôi. Cố gắng làm việc trên nhiều nhánh là không thể, vì nó sẽ mất hầu hết một ngày để kiểm tra một bản sao làm việc mới. Việc đẩy mạnh vào một kho lưu trữ của nhà cung cấp riêng biệt đã giúp, nhưng vẫn phải mất hàng giờ để trả phòng.

Tôi đã chuyển nhóm thành git. Để cung cấp cho bạn một ý tưởng về SVN tốt hơn bao nhiêu, tôi vừa tạo một kho chứa bản phát hành 1.45.0, sau đó nhân bản nó qua mạng. (Nhân bản sao chép tất cả lịch sử kho lưu trữ, trong trường hợp này là một cam kết duy nhất và tạo một bản sao làm việc.)

Bản sao đó mất sáu phút.

Trong sáu giây đầu tiên, bản sao nén của kho lưu trữ được sao chép vào máy của tôi. Phần còn lại của thời gian đã được chi tiêu bằng văn bản tất cả những tập tin nhỏ.

Tôi chân thành khuyên bạn nên thử git. Các đường cong học tập là dốc, nhưng tôi nghi ngờ bạn sẽ nhận được nhiều tiền biên dịch hacking thực hiện trong thời gian nó sẽ mất để sao chép một bản sao của tăng.

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