Есть ли способ ускорить создание/сборку программного обеспечения? У нас есть дерево сборки c, C++, используя makefile, который приближается к 2Hrs для свежих сборок. Я столкнулся с несколькими коммерческими решениями, такими как ElectricAccelerator, Sparkbuild, есть ли какой-либо эквивалент с открытым исходным кодом?Советы по созданию сборок быстрее
Поиск в google может помочь в получении списка программ с открытым исходным кодом.
W.r.t код вы можете сделать следующие сократить время сборки:
Хотел бы я сделать несколько +1! –
@SylvainDefresne: Спасибо :) –
Что такое * include declarations *? –
Один из способов - просто запустить сборку на более быстром оборудовании. Я понимаю, что это не всегда вариант, но это все еще что-то рассмотреть.
Как упоминает @Martin, некоторые конкретные подсистемы для обновления включают в себя использование как можно большего количества дисков, таких как SSD, добавление большего количества оперативной памяти, более быстрый процессор (и больше ядер, если ваш компилятор может их использовать) и убедитесь, что создаваемые файлы являются локальными для машины сборки (не в сети).
Вы также должны предоставить процесс сборки как можно большему количеству этого пула ресурсов, чтобы исключить все процессы и приложения, не связанные с сборкой, из машины сборки. Это уменьшит любой конфликт ресурсов.
Да - быстрые массивы SSD, загружает ОЗУ, копирует источник в локальные папки для сборки. –
Точно. Устранение узких мест на строительной машине имеет решающее значение.Спасибо за добавление определенных элементов для обновления. – cdeszaq
.. и серфинг, bitTorrent и игры выполняются очень быстро (в те короткие перерывы между сборками :) –
В нашей компании у нас было много продуктов, которые имеют более длительное время сборки, например, 3-6 часов.
Есть 2 техники, которые мы использовали.
-j выбору make«Время сборки, как 3-6 часов» - ох! Думаю, я найду новую работу .. :) –
@MartinJames Не волнуйтесь, Хадсон делает это для меня. –
Предварительно скомпилированные заголовки могут, если они используются правильно, резко сокращают время сборки.
Мы используем комбинацию distmake, ccache и makefile-generator, которая создает параллелизуемый make-файл. C/C++ сборки могут распараллеливаться очень хорошо; часто все файлы .o могут быть скомпилированы параллельно.
Distmake - это распределенная реализация make, основанная на gnu make и выпущенная под GPL. Я поддерживаю это. Он позволяет распараллеливать несколько хостов. Это требует, чтобы все хосты имели одинаковый вид файловой системы, например. NFS, так что одна и та же команда может запускаться на любом хосте сборки.
Отключение оптимизации будет иметь тенденцию производить более быстрые сборки, если у вас есть эта опция.
Если вы уже используете параллельную архитектуру сборки и она все еще медленная, вам просто нужно ее изучить. Наблюдайте за его прогрессом с секундомером и смотрите, где это узкие места. Ищите «длинные полюса», которые, возможно, вы не ожидали. Удачи.
Вы не указали конфигурационное программное обеспечение, но обнаружили неполадку с clearcase. Из-за того, как он оценивает правила файла по файлу, просто открытие файла может быть узким местом. Только даже подумайте о том, чтобы читать дальше, если вы «застряли» с чемоданом.
Итак, мы обнаружили, что, изменив ваши защитные ограждения для заголовочных файлов, вы можете сократить время сборки до 1/30-го времени (для нас это было сделано).
В основном, в файлах заголовков, то есть включаемый охранник наверху, как:
#ifndef FOO_H
#define FOO_H
your code
#endif
Потом куда-то еще, вы #include foo.h. Правильно, мы обнаружили, что из-за некоторой ужасной связи файлов типов и таких, что некоторые общие заголовки были включены сотни раз для каждого .c файла, который мы скомпилировали. С недостатком дизайна ясности, это означает, что сотни раз открывают каждый из этих файлов, чтобы игнорировать содержимое и снова закрыть файл.
Итак, вместо #include для foo используйте защитник, чтобы условно включить foo. Обычно это плохая практика и ужасный кошмар обслуживания (если кто-то начинает менять охранников).
Так .. в файле .c, вы бы в конечном итоге делает что-то вроде:
#include <stdio.h>
#ifndef FOO_H
#include "foo.h"
#endif
#ifndef FOO_H
#include "foo.h"
#endif
... rest of your code implementation
Как я уже сказал ... плохая практика, но если вы используете ClearCase и его кусает вас с 3 -4 времени сборки (например, у нас было) ... может быть стоит рассмотреть (или просто сделать копию всего дерева за пределами ясности). Или прояснить ситуацию. Или сделайте лучшую работу с межзависимыми типами.
Мы смогли «исправить» некоторые из наиболее часто используемых включений и добиться довольно значительного улучшения времени сборки.
ДВА ЧАСА! В прошлый раз я видел, как время сборки было перегружено VAX. Возможно, это очень большой проект. Что вы строите? Все ли файлы на сетевых дисках или скопированы на локальные? –
@MartinJames Я видел 6 часов времени сборки для какого-то проекта lisp, c, java. –
@ Сиплу - Мне очень жаль ... Я бы с ума сошел. Если сборка идет не так после 5,9 часов, как вы перестаете прыгать с высокого здания? Что вы делаете с разработчиком, создавшим неразрешенный внешний - это очень больно? –