Pull to refresh

Comments 9

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

А почему бы не править исходники хуками в момент добавления в репозиторий?

Дело в том что при отладке прошивок нам приходится собирать прошивки локально из WorkSpace (до загрузки в репу). Поэтому надо чтобы подпись отрабатывала локально.

И кстати, исходники при сборке править не нужно - это вообще крайне дурная практика, так как у вас код не совпадает с эталоном и нет повторяемости сборки. Для этого есть опции линкера, позволяющие задавать значения символов через опции командной строки. Увлекательно, но зато правильно.

Ну, вот, чтобы всё работало хорошо и нужно один раз напрячься и прикрутить автоинкремент версии при добавлении в репозиторий. И установку флагов и дат при переносе в релизные и пререлизные ветки.
Для локальных неррелизный сборок никто не запрещяет использовать флаги версий и ревизий. И добавление даты сборки, если сильно хочется.

А у вас куча, судя по всему, оно ещё и криво всё сделано. У вас, что при сборке обновляется дерево исходников? Это плохо.

Если хочется вот такой велосипед, то вынесите версию (именно верснию) в отдельный файл в корне проекта, например. И прикрутите автоикремент при релизной сборке или комите в репозиторий. И дату фиксации исходников туда же. И флаги релизная/пререлизная/тестовая сборка. И номер билда туда же.
А сборку настройте так, чтобы версия бралась их этого файла, но при этом не обновляла файлы в дереве исходников (чтобы факт сборки не влиял на исходники). Желательно через ключи линкера - всё отлично уместиться в несколько 32-битных символов.
Вот тогда правильно будет. У вас будет удобная человеко-читаемая автоматически обноляемая информация о версии, и при этом сохранится повторяемость сборки. И не будет зависимости от репозитория. И при заливке в репозиторий в резлизные ветки, чтобы тэги по версии автоматов выставлялись. Вот это будет правильно и по-взрослому.

А сейчас у вас бардак и в версиях и в репозитории. Как узнать какая версия новее? Как узнать релизная ли это версия или тестовая? Что вообще даёт эта "подпись", если у вас под рукой нет репозитория? Что делать при сборке из другого репозитория? Что делать, если нужно собрать версию где-то в полях - как потом понять, что это вообще за версия? Что будет, если вам нужно будет по техническим причинам перенести репозиторий? А если нужно будет отрефакторить историю? А если нужно из архива собрать? А если нужно для заказчика сдать/зафиксировать версию? Весь репозиторий с историей будете ему в арахив пихать? Где повторяемость сборки бинарных артефактов? Как это потом можно сертифицировать в случае необходимости?

Нечего в исходниках делать переменной информации.

А гит или что-то аналогичное использовать полезно ?

Нечего версии продукта делать в исходниках? смело.

Можно сделать проще:

Используем make

GIT_SHA := $(shell git rev-parse --short HEAD)

# ...
DEFINES += GIT_SHA=0x0$(GIT_SHA) # можно сделатьстроку если надо
C_DEFS = $(addprefix -D,$(DEFINES))
# ...

Используем в коде

printf("FW version : %d.%d.%d (%08x)\n", FIRMWARE_VERSION_MAJOR, FIRMWARE_VERSION_MINOR, FIRMWARE_PATCH, GIT_SHA)

Для идентификации имя ветки избыточно, достаточно хэша комита

Гениально! 3 строчки.

    GIT_SHA := $(shell git rev-parse --short HEAD)
    OPT += -DGIT_SHA=0x0$(GIT_SHA)
    .....
    LOG_INFO(SYS,"GitSha: 0x%08x", GIT_SHA);

Если вам не нужно числовое представление, то лучше сразу в строку загонять, будет еще лаконичнее

LOG_INFO(SYS,"GitSha: " GIT_SHA);

к тому же, без лишних вычислений.

Вот поэтому и надо пользоваться makefile(лами).
В makefile всё делается лаконично.

А GUI-IDEшкам такое и не снилось!

Sign up to leave a comment.

Articles