Предотвращение ненужных перекомпиляций с использованием «ветвистой» модели разработки

Question

Я использую Mercurial для разработки довольно крупного проекта на C ++, сборка которого занимает около 30 минут (в то время как инкрементные сборки выполняются очень быстро).

Я обычно пытаюсь реализовать каждую новую функцию в новой ветви (используя "hg clone"), и у меня может быть несколько новых функций, разработанных в течение дня, и быстро становится очень скучно ждать, пока новая ветвь функции не получит встроенный.

Существуют ли какие-либо рецепты для повторного использования объектных файлов из других уже созданных веток?

P.S. в git есть именованные ветви внутри одного и того же репозитория, которые делают возможным повторное использование существующих объектных файлов для системы сборки, однако я предпочитаю более простую модель отдельных ветвей Mercurial ...

Answer 1

Я предлагаю использовать ccache как способ ускорить компиляцию (в основном) одного и того же кодового дерева. Это работает следующим образом:

• Вы определяете место, которое будет использоваться как кеш (и максимальный размер кеша), используя переменную окружения CCACHE_DIR
• Ваш компилятор должен быть установлен на ccache ${CC} или ccache ${CXX}

ccache принимает вывод ${CC} -E и флаги компиляции и использует его в качестве основы для своего хэша. Пока флаги компилятора, исходный файл и заголовки остаются неизменными, объектный файл будет взят из кэша, что сэкономит ценное время компиляции.

Обратите внимание, что этот метод ускоряет компиляцию любого исходного файла, который в итоге выдает тот же хеш. Если вы делитесь исходными файлами между проектами, ccache также будет обрабатывать их.

Если вы уже используете distcc и хотите использовать его с ccache, установите для переменной среды CCACHE_PREFIX значение distcc.

Использование ccache ускорило компиляцию нашего исходного дерева примерно в десять раз.

Answer 2

Простой способ ускорить сборку - использовать локальный «каталог сборки» на вашем диске. Таким образом, вы можете зайти в этот каталог и начать сборку. В первый раз это займет все время, но после этого (надеюсь) будет перестраивать только те файлы, в которых изменился исходный код.

Answer 3

My Расширение локальной ветви было разработано частично для этого варианта использования. Он использует один рабочий каталог, но я думаю, что это проще, чем git. По сути, это механизм поддержки нескольких клонов репозитория в одном рабочем каталоге, где в данный момент активен только один.

Answer 4

Woops, я скучал по твоему P.S. где вам не нравится иметь несколько именованных веток в одном репо и вы предпочитаете отдельные клоны ... извините за это.

У меня тоже есть несколько больших проектов на C ++, и рабочий процесс клонирования по функциям работал не очень хорошо для меня. Во-первых, мне пришлось закрыть сеанс Vim, а затем снова открыть (многие из тех же) файлов, как только я создал клон. Во-вторых, как вы сказали, много кода должно быть перекомпилировано без необходимости. В-третьих, я должен следить за тем, куда я толкнул и откуда вытащил - запутывается, когда вы запускаете новую функцию, а затем отвлекаетесь на новую. Прежде чем вы это узнаете, у вас есть много клонов, и вы не знаете, какие из них нужно отодвинуть назад к вашей главной.

Вы определенно не хотите использовать именованные ветви (как я уверен, что вы знаете), чтобы справиться с этим, поскольку они довольно постоянны.

Вам нужны закладки: https://www.mercurial -scm.org / wiki / BookmarksExtension

Закладки позволяют создавать легкие (и в других случаях анонимные) ветви для каждой функции, облегчая именование голов в вашем репо. Эти заголовки обычно бывают безымянными, и вам придется посмотреть на вывод hg log или использовать какой-нибудь графический инструмент, чтобы найти номера ревизий для кончика вашей ветви функций. С помощью закладок вы можете называть их описательными именами, например, «my-cool-feature» или «bugfix-392».

Если вам нравится идея закладок, я бы также порекомендовал мое собственное расширение под названием 'tasks': http://bitbucket.org/alu/hgtasks. Это расширение работает как закладки, но добавляет некоторые дополнительные функции. Это позволяет вам создавать ветви функций (теперь называемые задачами) и подавлять нажатие незавершенных задач. Это удобно, когда у вас есть несколько ветвей функций одновременно. Возможно, вы не готовы выполнить задачу my-cool-feature, но bugfix-392 готов к работе. Поскольку задачи отслеживают набор изменений (а не только один набор изменений), есть некоторые вещи, которые вы можете делать с задачами, которые нельзя делать с закладками. Смотрите пример рабочего процесса здесь: http://x.zpuppet.org/2009/03/09/mercurial-tasks-extension/.

Answer 5

Mercurial также имеет локальные именованные ветви, см. Команду hg branch.

Если вы настаиваете на использовании hg clone для разработки веток, я думаю, вы можете попытаться создать ссылку на папку (ярлык под windows) в вашем репо на общую папку obj. Это будет работать с hg clone, но я не уверен, что ваш инструмент сборки подберет его.

В противном случае, вы, вероятно, храните все свои репозитории в одной папке - просто поместите туда папку obj (в любом случае она не должна находиться под контролем исходного кода, imo). Используйте относительные пути для ссылки на него.

Answer 6

Слово предупреждения: многие таблицы символов .o (или эквивалентные) содержат полный путь к исходному файлу. Если этот другой файл изменяется (или если путь не виден из нового каталога), вы можете столкнуться со странностями при отладке.