Просто добавление документации вызывает перекомпиляцию: есть ли решение?

Question

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

Но тогда я думаю: о нет, это вызовет перекомпиляцию при следующем make вызове! И для определенных базовых заголовков весь проект будет перекомпилирован, что может занять много времени. Так что, не бери в голову!

Есть ли решение этой дилеммы? Существуют ли подходы, в которых функции / классы документируются не непосредственно в заголовках? Или есть (в планах) смарт make, который бы заметил, что изменился только какой-то комментарий, но перекомпиляция не требуется?

Answer 1

Вы можете сократить время компиляции, используя ccache , возможно, с установленным параметром среды CCACHE_UNIFY.

ccache хэширует выходные данные препроцессора и обслуживает ранее скомпилированный объект, если не было обнаружено никаких изменений.

Раздел справочной страницы о CCACHE_UNIFY

CCACHE_UNIFY

Если вы установите переменную окружения CCACHE_UNIFY, тогда ccache будет использовать унификатор C / C ++ при хешировании вывода препроцессора если -g не используется в компиляции. Объединитель медленнее, чем обычный хеш, поэтому установка этой переменной среды немного теряет немного скорости, но это означает, что ccache может воспользоваться не перекомпиляция, когда изменения в исходном коде состоят из только переформатирование. Обратите внимание, что использование CCACHE_UNIFY изменяет хеш, поэтому кэшированные компиляции с установленным CCACHE_UNIFY не могут быть использованы когда CCACHE_UNIFY не установлен и наоборот. Причина объединитель по умолчанию отключено, что может дать неверный номер строки информация в предупреждающих сообщениях компилятора.

Answer 2

Как насчет проверки (вы делаете контроль версий, не так ли?) другая копия кодовой базы в другом каталоге, только для такого рода правок?

Это может быть отдельная ветка или нет. Затем, когда такие небольшие изменения происходят с вами, вы просто делаете их здесь. Вы можете передать их напрямую: теперь они находятся в безопасном месте и не будут мешать вашему реальному развитию. Время от времени, например, раз в неделю, если время сборки действительно так велико, вы можете объединить эти изменения с тем, над чем вы работаете. Конфликты слияний возникают редко, если вы документируете в одном каталоге и пишете код в другом.

Answer 3

Почему бы просто не коснуться файла назад во время, когда make не будет думать, что он изменился?

Как кто-то предлагает, вы можете обернуть его в простой скрипт.

Answer 4

make работает строго по временным меткам на файлах, и, безусловно, нет никаких планов расширять его после этого. make используется для многих вещей, кроме C, и ничего не знает о содержимом файла. Ваша сборка, вероятно, станет намного медленнее, если make будет анализировать изменения.

Вы можете хранить свою документацию в файлах заголовков и только в файлах .c, что ограничит объем того, что необходимо перекомпилировать. Я признаю, что лично я предпочитаю документировать «интерфейсные» функции в заголовочных файлах, но с точки зрения doxygen это не имеет большого значения.

Как предлагает другой, вы можете обойти эту систему, используя «прикосновение» к дате создания файла.

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

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

Answer 5

Мое решение состоит в том, чтобы просто не включать заголовки в качестве зависимостей в Makefile ... так, чтобы изменения в заголовочном файле не вызывали перекомпиляцию командой "make".

Конечно, недостатком этого является то, что если я внесу изменение, которое повлияет на макеты памяти (например, добавив переменную-член в класс), мне нужно помнить, чтобы вручную коснуться затронутых файлов .cpp (или, если это слишком сложно понять чтобы выяснить, какие файлы cpp затронуты, выполните команду "make clean; make"), которая может быть немного подвержена ошибкам ... но в целом это работает для меня.

Answer 6

Просто внесите изменения и примите перекомпиляцию. На самом деле невозможно иметь функциональную среду разработки, когда разработчики боятся комплиментов; Возможно, вам нужно изучить систему компиляции распределенной сетки, которая сократит время компиляции?