Как стать автором
Обновить

Интеграция clang-format в Процесс Сборки

Уровень сложностиПростой
Время на прочтение5 мин
Количество просмотров2.9K

Есть такая утилита для автоматического выравнивания отступов в исходных кодах. Называется clang-format.exe. Надо признать, что сейчас де факто основной утилитой автоматического выравнивания отступов является именно утилита clang-format.exe из LLVM. Её достоинство в том что ей всё равно в каком текстовом редакторе вы пишите код. Что в Eclipse, что Notepad++, что MS Visual Code. Сlang-format он выровняет всё, что ему подадут на вход в соответствии с указанным конфигом в опциях командной строки.

Есть еще тоже консольный GNU indent, однако indent очень устарел и слаб. Плюс падает от обнаружения препроцессора.

Цель данного текста- показать, как интегрировать clang-format в процесс сборки прошивки.

Почему обычно делают форматирование отступов в исходниках?

На то я вижу минимум три причины:

1--Для однообразности и красоты. В каждой российской компании свой собственный, внутренний, ни на кого больше не похожий стандарт оформления исходных текстов программ на Си. Причем отличается обычно на 80%..90% от других организаций.

2--Чтобы был минимальный diff при сравнении разных по времени версий одного и того же куска Си кода

3--Чтобы можно было составлять простые и предсказуемые регулярные выражения для поиска шаблонов кусков кода утилитой grep и find в репозитории с кодом.

В чем проблема?

Проблем тут две:

1--Первая проблема в том, что вручную выставлять отступы это очень утомительно и рутинно. Однако эта проблема решается, как раз, утилитами автоматического выставления отступов.

2--Вторая проблема в том, что для автоматического форматирования кода утилитами приходится составлять *.bat файл и явно прописывать внутри какой файл надо форматировать. Это тоже очень рутинно с учетом, что файлов в сборке порядка нескольких сотен. Вот у меня типичная сборка собирает 237 с-файликов. И что, мне прописывать 237 строчки в bat файле что ли?

Очевидно же, что надо как-то автоматизировать процесс прогона с-файлов через утилиту форматировщик clang-format.

Решение

Попробуем запустить clang-format автоматически из скриптов сборки. Проще говоря, надо вмонтировать утилиту автоматического выравнивания прямо в систему сборки прошивки.

Что надо из софта?

#

Название утилиты

Назначение

1

grep

рекурсивный поиск по файловой системе

2

sed

утилита авто замены ключевых слов в файлах

3

make

утилита управления системой сборки

4

clang-format

утилита автоматического выравнивания исходных кодов

Можно написать отдельный make файл для вызова этой утилиты. Вот по такой схеме.

Вот такой Make скрипт сам производит выравнивание тех же самых файлов, что участвовали в сборке прошивки.

$(info ClangFormatScript)

CLANG_FORMAT_TOOL =C:/cygwin64/bin/clang-format.exe
SOURCES_CF := $(subst .c,.cf, $(SOURCES_C))

#$(error SOURCES_CF=$(SOURCES_CF))

MCAL_STYLE="{
MCAL_STYLE+= BreakBeforeBraces: Attach,
MCAL_STYLE+= ColumnLimit: 120,
MCAL_STYLE+= IndentWidth: 4,
MCAL_STYLE+= PointerAlignment: Left,
MCAL_STYLE+= SortUsingDeclarations: true,
MCAL_STYLE+= SpaceBeforeParens: Never,
MCAL_STYLE+= SortIncludes: true,
MCAL_STYLE+= TabWidth: 4,
MCAL_STYLE+= UseTab: Never,
MCAL_STYLE+=}"
#$(error MCAL_STYLE=$(MCAL_STYLE))

%.cf: %.c
	$(info RunClangFormat)
	$(CLANG_FORMAT_TOOL) -verbose -i -style=$(MCAL_STYLE) $<

.PHONY: clang_format
clang_format: $(SOURCES_CF)
	$(info ClangFormatDone)

Однако есть один момент. Не все файлы исходников следует подвергать автоматическому выравниванию. Дело в том, что если ты меняешь форматирование в файле, то ты, как бы, автоматически становишься владельцем этого кода. Оно тебе надо? Ты же не хочешь нести ответственность за этот странный чужой код просто потому, что ты там поменял TAB на 4 пробела? Поэтому существует такое негласное правило буравчика:

Ни в коем случае нельзя менять форматирование в чужом коде!

Очевидно, что в скриптах сборки надо как-то пометить те файлы сорцов, которые мы не будем форматировать. Это могут быть сорцы с конфигурационными таблицами для GPIO, таймеров.

Это надо оставить без форматирования
Это надо оставить без форматирования

Надо чтобы они и остались в первозданном виде таблиц.

Дак вот, в системе сборки make сделать это очень просто. Надо всего-навсего проиндексировать чужие сорцы в переменную окружения SOURCES_THIRD_PARTY_C.

ifneq ($(FAT_FS_MK_INC),Y)
    FAT_FS_MK_INC=Y

    FAT_FS_DIR += $(THIRD_PARTY_DIR)/fat_fs
    #@echo $(error FAT_FS_DIR= $(FAT_FS_DIR))
    INCDIR += -I$(FAT_FS_DIR)
    INCDIR += -I$(FAT_FS_DIR)/src
    INCDIR += -I$(FAT_FS_DIR)/src/options

    SOURCES_THIRD_PARTY_C += $(FAT_FS_DIR)/src/diskio.c
    #SOURCES_THIRD_PARTY_C += $(FAT_FS_DIR)/src/option/unicode.c
    SOURCES_THIRD_PARTY_C += $(FAT_FS_DIR)/src/option/ccsbcs.c
    SOURCES_THIRD_PARTY_C += $(FAT_FS_DIR)/src/ff.c
endif

Если лень это производить вручную, то можно применить этот bash скрипт

grep -rl SOURCES_C . | xargs sed -i 's/SOURCES_C/SOURCES_THIRD_PARTY_C/g'
grep -rl SOURCES_C . | xargs sed -i 's/SOURCES_C/SOURCES_CONFIGURATION_C/g'

Далее в rules.mk просуммировать те сорцы, которые мы форматируем SOURCES_C и те, которые мы не форматируем SOURCES_THIRD_PARTY_C в одну переменную окружения SOURCES_TOTAL_C


SOURCES_TOTAL_C += $(SOURCES_C)
SOURCES_TOTAL_C += $(SOURCES_THIRD_PARTY_C)
SOURCES_TOTAL_C += $(SOURCES_CONFIGURATION_C)
SOURCES_TOTAL_C := $(subst /cygdrive/c/,C:/, $(SOURCES_TOTAL_C))

Вот так получается, что THIRD PARTY и CONFIGURATION код останется без изменений. Всё что надо - это открыть папку с проектом из консоли и набрать

make clang_format

Все нужные с-файлы станут с выровненными отступами. Автоматически... Крастота!

Достоинства форматирования из-под скриптов сборки (Make)

++Форматирование отступов из-под системы сборки тем хорошо, что вы можете к одной и той же кодовой базе в репозитории применять различные форматирования в зависимости от программного компонента. Например две команды разработчиков в одно репе работают.

В то время как форматирование git hook (ами) заставляет причесывать весь репозиторий под одну гребёнку. А это порой недопустимо.

++Дело в том, что далеко не все компании вообще используют системы контроля версий. Там даже понятие такое как "коммит" отсутствует. Вот в секретном военных НИИ мы писали прошивки для электронных плат и прошивки передавали в *.zip архиве через USB флешку, или архивом по электронной почте. Никакой системы контроля версий вообще не было из-за конспирации.

Итоги

Как видите, сборка из скриптов (в частности make) дает такие преимущества как автоматическое выравнивание отступов исходного кода.

Понятное дело, что если вы собираете программы из IDE мышкой, то вам такое не доступно в принципе. Поэтому имеет смысл задуматься о переносе на сборки скриптами.

А с Make удалось с полпинка вмонтировать утилиту clang-format в основной конвейер сборки прошивки. Успех!

Словарь

акроним

расшифровка

LLVM

Low Level Virtual Machine

bash

Bourne again shell

GNU

GNU’s Not UNIX

sed

Stream EDitor

grep

search Globally for lines matching the Regular Expression, and Print them

Ссылки

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Как вы выравниваете отступы в исходниках?
16.67% Никак. Зачем мне это нужно?..5
16.67% Вручную: курсором мышки, кнопкой space, backspaсe и delete5
6.67% утилитой clang-format и bat файлом2
0% утилитой GNU Indent0
16.67% Средствами IDE Eclipse: Select, Ctrl+Shift+F5
13.33% утилитой clang-format из скриптов сборки4
30% Другое9
Проголосовали 30 пользователей. Воздержались 3 пользователя.
Теги:
Хабы:
Всего голосов 14: ↑5 и ↓9+2
Комментарии25

Публикации

Работа

DevOps инженер
35 вакансий
Программист С
35 вакансий

Ближайшие события