[Brain13 0]

Здравствуйте.

Появилась задача точно определять какая прошивка залита в МК. Для этого планирую записывать некоторое число в прогу МК и по необходимости читать его через последовательный порт. Но при каждой заливке лезть и изменять это число запарюсь, да и забыть можно. Хотелось бы, чтобы это число инкрементировалось само при каждой компиляции. Как это сделать.

Системы контроля версий не использую, но надо начинать. Насколько я понимаю в системах типа Git, Svn есть номер ревизии. Можно ли как нибудь это использовать?

Может в Eclipse есть какаянидь фича для этого?

Думаю сделать следующее: написать скрипт который вызывается при компиляции, он считывает файл, например, "version.h" и инкрементирует какойнидь define.

 

А как делается правильно?

 

PS: Использую Ubuntu+Eclipse+CodeSourcery G++ + GNU ARM Eclipse Plugin.

[Flexz 0]

Предпочитаю дату компиляции, более наглядно получается. Если без SVN, то make перед компиляцией вызывает скрипт, который пишет в файл, например, date.h текущую дату, которую потом можно показать пользователю или считать как-то.

Если с SVN то см. svn:keywords. Про git не знаю, не довелось поюзать пока.

 

[MrYuran 29]

Предпочитаю дату компиляции, более наглядно получается. Если без SVN, то make перед компиляцией вызывает скрипт, который пишет в файл, например, date.h

++

Вместо скрипта можно использовать предопределённую константу компилятора __DATE__

 

Номер версии инкрементирую вручную при первой правке текущей стабильной версии.

После ряда итераций и конечного тестирования-прогона она автоматически релизится в качестве новой стабильной версии и закладывается в архив.

[xvr 12]

Я использовал для этих целей скрипт, который сканировал все исходные файлы (с сорцами), предварительно отсортировав их по имени, и вычислял MD5 от всех файлов скопом. Потом генерил С текст с массивом с этой MD5 и прилинковывал его в конечную прошивку

 

[haker_fox 61]

Я использовал для этих целей скрипт, который сканировал все исходные файлы (с сорцами), предварительно отсортировав их по имени, и вычислял MD5 от всех файлов скопом. Потом генерил С текст с массивом с этой MD5 и прилинковывал его в конечную прошивку

Подождите, а автор топика кажется о версии спрашивал?!

[Ruslan1 17]

Хотелось бы, чтобы это число инкрементировалось само при каждой компиляции.

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

 

Хотя туплю я, часто можно дебаг и релиз по-разному собирать, если так то тогда да, релизов много не бывает, можно и автоматом номер инкрементировать.

[Brain13 0]

При каждой компиляции это как-то жестко, у меня и сотня мейков в день бывает, и каждому новый номер давать? ...

Да, каждой компиляции - свой номер. Я такое видел, например, в AVR Studio, там в хелп о програме было примерно следующее 4.18 SP2, Build 678.

 

Для чего это нужно: отдают мне плату и говорять что там баг. Мне нужно залезть в нее отладчиком. А исходники к этому времени изменились. Да и не помню какая версия там была(месяца полтора прошло). Как отлаживать, перезаливать нельзя, тк баг может измениться.

Так вот малйшее изменение должно отслеживаться. А вручную проставлять геморно и можно забыть прописать номер.

 

Написал простенький скрипт для этих целей

#!/bin/sh

filename=../version.h  #путь до файла с версией

if [ -f $filename ] #если файл существует
then
while read line #поиск по всему файлу
do
	if [[ ${line:0:24} == "#define _BUILD_NUMBER__ " ]] # вот этой строки
	then
		build_number=${line:24} # с 24 символа считать предыдущий номер билда
		build_number=$((build_number+1)) # инкремент
		break
	else
		build_number=1
	fi
done <$filename
else 
build_number=1
fi

build_date=$(date +%Y%m%d%k%M%S) # берем дату

echo "_BUILD_NUMBER__	= $build_number" # при построении будет отображаться текущий номер и дата
echo "_BUILD_DATE__	= $build_date"



rm -Rf $filename # удаляем старый файл

echo "#ifndef _VERSION_H__" >> $filename
echo "#define _VERSION_H__" >> $filename

echo "#define _BUILD_NUMBER__ $build_number" >> $filename # тут просто число
echo "#define _BUILD_DATE__ \"$build_date\"" >> $filename # тут строка т.к. число большое ИМХО лучше строкой
echo "#endif" >> $filename
echo  >> $filename

Прошу за код не пинать - это мой первый скрипт на баше.

 

Этот код можно вызвать перед построением. В эслипсе это прописыватся в Properties -> C/C++ Build -> Setings -> Build Steps -> Pre-Build Steps -> Command. Там я прописал "sh /home/brain/workspace/arm/test_ml/version.sh"

сча думаю как еще дописать, чтоб этот скрипт в git коммит сам делал, вроде это должно быть не сложно. Когда допишу наверна выложу здесь.

[sergeeff 1]

Да, каждой компиляции - свой номер.

 

Так база git'a разбухнет до неимоверности, если туда commit автоматом каждый make делать. Да и как-то странно, у вас серийное изделие в постоянной доработке?

[xvr 12]

Подождите, а автор топика кажется о версии спрашивал?!

А чем собственно не версия? Слишком букв много для номера версии? Что есть, то есть :rolleyes:

Зато однозначно связывает сорцы и версию. Конечно, эти сорцы должны где то быть. Т.е. нужна или версионная система (SVN, Git, CVS, etc) или тупо директория с заархивированными сорцами.

 

Если есть версионная система, то можно номер версии из нее закатать в прошивку (это делается скриптами и опцией -D компилятора)

 

[Brain13 0]

Так база git'a разбухнет до неимоверности, если туда commit автоматом каждый make делать. Да и как-то странно, у вас серийное изделие в постоянной доработке?

 

Это не серийное изделие, пока идет разработка. Насколько я знаю git хранит только первоначальный файл, и кучу diff'ов к нему, поэтому размер должен быть небольшой. Да и размер репозитория не критичен, хоть десяток Гб. Вот не пострадает ли скорость, хотя врядли, linux на гите работает и ничего, а там миллион коммитов наверно есть.

 

...

Если есть версионная система, то можно номер версии из нее закатать в прошивку (это делается скриптами и опцией -D компилятора)

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

 

[sergeeff 1]

Почитайте здесь: http://www.codeproject.com/KB/architecture...ual_studio.aspx

[Idle 0]

Здравствуйте.

...

Но при каждой заливке лезть и изменять это число запарюсь, да и забыть можно. Хотелось бы, чтобы это число инкрементировалось само при каждой компиляции.

здравствуйте, зачем вам менять число при каждой прошивке? пишешь функционал, отлаживаешь, отладил - версия такая-то, вручную проставляешь

 

[sergeeff 1]

Абсолютно поддерживаю. Тем более, что, например, в SVN автоматом номера версии автоматом появляются только в измененных файлах. Значит встанет вопрос об "отлавливании" максимального номера версии из всех файлов проекта или же вручную смотреть средствами SVN текущую ревизию и ее добавлять в том или ином виде в проект.

[xvr 12]

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

Не надо в код, встраивайте через опции в Makefile'е

Пишете скрипт, который извлекает из вашей версионной системы текущую версию HEAD'а (не знаю, как это будет в git - не пользую)

Затем передаете ее в make, например так:

make VERSION="$VERSION"

Предполагается, что в переменной окружения VERSION лежит ваша версия, и она есть число

В самом makefile'е пишете так

  $(CC) ... -DVERSION=$VERSION

Где то в программе пишете

int my_version = VERSION;

Все - в переменной my_version у вас версия репозитария на момент компиляции

 

[slavka012 0]

Для чего это нужно: отдают мне плату и говорять что там баг. Мне нужно залезть в нее отладчиком. А исходники к этому времени изменились. Да и не помню какая версия там была(месяца полтора прошло). Как отлаживать, перезаливать нельзя, тк баг может измениться.

Так вот малйшее изменение должно отслеживаться. А вручную проставлять геморно и можно забыть прописать номер.

Проблема конечно актуальная, но решение.... Ужасное. Захотелось посмотреть историю проекта, и что мы видим? Сотни модификаций, без каких либо аннотаций? Это жесть.

 

Гораздо разумнее перед тем как отдавать версию заказчику комиттить все изменения в version control, обновлять build #, и после сборки тудаже заливать исходник. Все таки, очередная версия в SVN должна представлять собой какой-то маломальски законченый шаг в развитии проекта, либо исправление бага, либо новая функция.