Có cách nào để làm cho việc xây dựng/biên dịch phần mềm nhanh hơn không? Chúng tôi có một cây xây dựng c, C++ bằng cách sử dụng makefile mất gần 2Hrs để xây dựng mới. Tôi đã gặp vài giải pháp thương mại như ElectricAccelerator, Sparkbuild, có bất kỳ mã nguồn mở nào tương đương không?Mẹo để tạo các bản dựng nhanh hơn
Tìm kiếm trên google có thể giúp bạn trong việc nhận danh sách các phần mềm nguồn mở.
W.r.t mã của bạn, bạn có thể làm như sau để giảm build lần:
Tôi ước tôi có thể làm nhiều +1! –
@SylvainDefresne: Cảm ơn :) –
* khai báo bao gồm * là gì? –
Một cách đơn giản là chạy bản dựng trên phần cứng nhanh hơn. Tôi nhận thấy rằng đây không phải là luôn là một tùy chọn, nhưng đó vẫn là điều cần cân nhắc.
Như @Martin đề cập, một số hệ thống con cụ thể để nâng cấp bao gồm sử dụng đĩa nhanh như bạn có thể, như SSD, thêm RAM, CPU nhanh hơn (và nhiều lõi hơn, nếu trình biên dịch của bạn có thể sử dụng chúng), và đảm bảo các tệp đang được xây dựng đều là cục bộ cho máy xây dựng (không phải trên mạng).
Bạn cũng nên cung cấp cho quá trình xây dựng càng nhiều hồ bơi tài nguyên này càng tốt, vì vậy hãy loại bỏ tất cả các quy trình và ứng dụng không liên quan đến xây dựng khỏi máy xây dựng. Điều này sẽ giảm bớt bất kỳ tranh chấp tài nguyên nào.
Có - mảng SSD nhanh, tải RAM, sao chép nguồn vào thư mục cục bộ để tạo. –
Chính xác. Loại bỏ tắc nghẽn trên máy xây dựng là rất quan trọng.Cảm ơn bạn đã thêm các mục cụ thể để nâng cấp. – cdeszaq
.. và lướt web, bitTorrent và trò chơi chạy rất nhanh, (trong những khoảng thời gian ngắn giữa các bản dựng :) –
Trong công ty chúng tôi, chúng tôi có rất nhiều sản phẩm có thời gian xây dựng lâu hơn như 3-6 giờ.
Có 2 kỹ thuật chúng tôi đã sử dụng.
-j tùy chọn make'thời gian xây dựng như 3-6 giờ' - ouch! Tôi nghĩ rằng tôi sẽ tìm một công việc mới .. :) –
@MartinJames Đừng lo lắng, Hudson làm điều đó cho tôi. –
Các tiêu đề được biên dịch sẵn có thể, nếu được sử dụng đúng cách, giảm đáng kể thời gian xây dựng.
Chúng tôi sử dụng kết hợp distmake, ccache và makefile-generator tạo ra tệp makefile song song. Các phiên bản C/C++ có thể song song rất tốt; thường tất cả các tệp .o đều có thể được biên dịch song song.
Distmake là triển khai thực hiện được phân phối, dựa trên gnu được tạo và phát hành theo GPL. Tôi duy trì nó. Nó cho phép bạn song song trên nhiều máy chủ. Điều này đòi hỏi tất cả các host có cùng một cái nhìn của hệ thống tập tin, ví dụ như. NFS, để cùng một lệnh có thể chạy trên bất kỳ máy chủ lưu trữ nào.
Tắt tối ưu hóa sẽ có xu hướng tạo ra các bản dựng nhanh hơn, nếu bạn có tùy chọn đó.
Nếu bạn đã sử dụng kiến trúc xây dựng song song và nó vẫn còn chậm, bạn có thể chỉ cần nghiên cứu nó. Theo dõi tiến độ của nó bằng đồng hồ bấm giờ và xem nó bị tắc nghẽn ở đâu. Tìm kiếm "cực dài" có lẽ bạn không mong đợi. Chúc may mắn.
Bạn không chỉ định phần mềm cấu hình của mình, nhưng chúng tôi đã phát hiện ra sự cố với chữ viết hoa. Bởi vì nó đánh giá các quy tắc trên một tệp theo cơ sở tệp, chỉ việc mở một tệp có thể là một nút cổ chai. Thậm chí chỉ xem xét đọc thêm nếu bạn "mắc kẹt" với chữ in hoa.
Vì vậy, chúng tôi phát hiện ra rằng bằng cách thay đổi bảo vệ bao gồm của bạn cho tệp tiêu đề, bạn có thể cắt thời gian xây dựng của bạn thành 1/30 thời gian (đối với chúng tôi).
Về cơ bản, trong các tập tin tiêu đề của bạn, bạn có một bao gồm bảo vệ ở phía trên như:
#ifndef FOO_H
#define FOO_H
your code
#endif
Sau đó tắt ở một nơi khác, bạn #include foo.h. Đúng, tốt, chúng tôi thấy rằng do một số khớp nối khủng khiếp của các loại tệp và sao cho một số tiêu đề phổ biến được đưa vào hàng trăm lần cho mỗi tệp .c mà chúng tôi đã biên soạn. Với lỗ hổng thiết kế rõ ràng, điều đó có nghĩa là mở từng tệp đó hàng trăm lần chỉ để bỏ qua nội dung và đóng lại tệp.
Vì vậy .. thay vì chỉ là #include cho foo, hãy sử dụng trình bảo vệ để có điều kiện bao gồm foo. Thông thường đây là thực hành xấu và một cơn ác mộng bảo trì khủng khiếp (nếu ai đó bắt đầu thay đổi các vệ sĩ).
Vì vậy .. trong file .c của bạn, bạn muốn kết thúc làm một cái gì đó như:
#include <stdio.h>
#ifndef FOO_H
#include "foo.h"
#endif
#ifndef FOO_H
#include "foo.h"
#endif
... rest of your code implementation
Như tôi đã nói ... thực hành xấu, nhưng nếu bạn đang sử dụng ClearCase và nó cắn bạn với 3 -4 lần xây dựng (như chúng tôi đã có) ... có thể đáng xem xét (hoặc chỉ làm một bản sao của toàn bộ cây của bạn bên ngoài chữ). Hoặc mương rõ ràng. Hoặc làm một công việc tốt hơn với kiểu phụ thuộc.
Chúng tôi có thể "sửa" một số trong số những mục đích được sử dụng nhiều nhất và đạt được sự cải thiện đáng kể trong thời gian xây dựng.
HAI GIỜ! Lần trước tôi thấy thời gian xây dựng như thế là trên các VAX quá tải. Có lẽ, đây là một dự án rất lớn. Bạn đang xây dựng ứng dụng nào? Tất cả các tệp trên ổ đĩa mạng hay được sao chép sang địa phương? –
@MartinJames Tôi đã thấy 6 giờ xây dựng thời gian cho một số dự án lisp, c, java. –
@Shiplu - Tôi rất xin lỗi ... Tôi sẽ phát điên. Nếu việc xây dựng xảy ra sau 5,9 giờ, làm thế nào để bạn dừng lại khi nhảy khỏi một tòa nhà cao? Bạn làm gì với nhà phát triển đã tạo ra bên ngoài chưa được giải quyết - liệu nó có đau không? –