Здравствуйте RmzVoid, Вы писали:
RV>Каким образом можно подсчитывать количество компиляций и билдов, чтобы например засунуть это число в About? RV>(Microsoft Visual C++ 6.0)
Эту тему уже обсуждали в форуме по MFC. Поищи "версия приложения".
Здравствуйте RmzVoid, Вы писали:
RV>Каким образом можно подсчитывать количество компиляций и билдов, чтобы например засунуть это число в About? RV>(Microsoft Visual C++ 6.0)
Можно написать макрос например:
Private Sub Application_BeforeBuildStart()
On Error Resume Next
Application.Documents.Open "Count.txt"
Dim vActDoc
Set vActDoc = Application.ActiveDocument
Dim vSelection
Set vSelection = vActDoc.Selection
vSelection.StartOfLine
vSelection.EndOfLine dsExtend
nCount = CInt( vSelection.Text ) + 1
vSelection = "" & nCount
vActDoc.Close dsSaveChangesYes
End Sub
Написано без проверки, потому возможны ошибки, прошу не пинать
Идея, там изложенная, страдает одним существенным неодостатком: ВСЕГДА, когда будет нажиматься F7 (Build) или F5 (Run), будет осуществляться сборка приложения, даже если исходные тексты не изменялись. Что сводит значимость номера сборки на нет
Правильнее было бы увеличивать номер сборки после ее окончания, только если бинарник действительно изменился. Такой подход реализован в Visual Build (и в BuildNumberIncreaser, наверное, тоже), но чем-то мне эта прога в свое время не понравилась, поэтому я сварганил собственную
Перед компоновкой (Pre-link step) запускается спец. программа, которая увеличивает номер сборки в rc-файле, и перекомпилирует его. Это, конечно, не совсем исключает указанный недостаток
// #import <windows.bas> class IWindows9x:protected DOS { private: virtual HANDLE EnumClouds()=0; };
KA>Идея, там изложенная, страдает одним существенным неодостатком: ВСЕГДА, когда будет нажиматься F7 (Build) или F5 (Run), будет осуществляться сборка приложения, даже если исходные тексты не изменялись. Что сводит значимость номера сборки на нет KA>Правильнее было бы увеличивать номер сборки после ее окончания, только если бинарник действительно изменился. Такой подход реализован в Visual Build (и в BuildNumberIncreaser, наверное, тоже), но чем-то мне эта прога в свое время не понравилась, поэтому я сварганил собственную KA>Перед компоновкой (Pre-link step) запускается спец. программа, которая увеличивает номер сборки в rc-файле, и перекомпилирует его. Это, конечно, не совсем исключает указанный недостаток
А у нас инкремент (перегенерация h-файла с #defin'ами) производиться при коммите изменений в CVS и ни каких лишних инкрементов нет
Если интересно — могу поподробнее.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте Коваленко Дмитрий, Вы писали:
КД>А у нас инкремент (перегенерация h-файла с #defin'ами) производиться при коммите изменений в CVS и ни каких лишних инкрементов нет
$Revision$? Угадал?
И этот Файл приходится постоянно отправлять в repository, даже если он не изменялся?
КД>Если интересно — могу поподробнее.
Давай!
// #import <windows.bas> class IWindows9x:protected DOS { private: virtual HANDLE EnumClouds()=0; };
Здравствуйте KA, Вы писали:
KA>Здравствуйте Коваленко Дмитрий, Вы писали:
КД>>А у нас инкремент (перегенерация h-файла с #defin'ами) производиться при коммите изменений в CVS и ни каких лишних инкрементов нет
KA>$Revision$? Угадал?
не CVSROOT/loginfo
KA>И этот Файл приходится постоянно отправлять в repository, даже если он не изменялся?
точно
сначало вытаскиваем из того-же CVS, изменяем, потом коммитим обратно.
КД>>Если интересно — могу поподробнее. KA>Давай!
где сначало указывается каталог при изменении содержимого которого будет увеличиваться номер версии. котороче каталог проекта.
потом указывается программа которая будет срабатывать на это действие. котороче объяснил
ax_ibprovider.bat содержит три команды
cvs get -l Version/ax_ibp_ver_info.dat Version/ax_ibp_ver_info.h
v:\CVSROOT\AutoInc\_auto_inc_build_no.exe Version\ax_ibp_ver_info.dat Version\ax_ibp_ver_info.h
cvs commit -m"inc_build_no" Version/ax_ibp_ver_info.dat Version/ax_ibp_ver_info.h
не примите за рекламу — просто единственный проект использующий все возможности инкременталки
_auto_inc_build_no — мое произведение, которое получает файл с параметрами описания версий и генерирует второй файл.
в архиве есть все три файла. типа прибайлдей с формата dat-файла. мой родной XML-парсер
На всякий пожарный — проверь на вирусы.
вот.
основные неудобства, которые я уже не замечаю
В CVS должен быть отдельный каталог для всех файлов с версиями. если bat файл будет дергать тот же самый проектный каталог — то произойдет блокировка.
после вытаскивания проекта из CVS нужно отдельно вытащить файлы с версиями. Обычно для этих целей в каталог проекта ложиться файл cvs_get_version.bat
Если меняется файлы подкталога проекта, то инкремент версии будет делаться именно в этом подкаталоге. Я пока не придумал нормального способа как это делать в одном месте. Поэтому после commit'a приходиться чистить подкаталоги (cvs release Version -d, кажется). С WinCVS это не сложно.
Иногда проходят непонятные сбои — когда инкрементруется версия другого проекта . Но это проблемы CVS а не мои. Он как-то (кажется начинает сравнивать с хвоста) странно определяет нужную запись в loginfo и иногда кидается на проект со схожим названием каталога.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
[skipped]
КД>основные неудобства, которые я уже не замечаю
[skipped]
Держи еще пару неудобств:
5. Работает ТОЛЬКО на Win32 с доступом по сетевому ресурсу (local).
6. Если файлы проект отправляются в repository не одной командой commit, а несколькими, то номер сборки получается другой.
// #import <windows.bas> class IWindows9x:protected DOS { private: virtual HANDLE EnumClouds()=0; };
KA> 6. Если файлы проект отправляются в repository не одной командой commit, а несколькими, то номер сборки получается другой.
Главное, что номер увеличивается. В ручную я выставляю только первые три цифры, которые и указываются как версия продукта. Четвертая у меня всегда [автоматически] растет только в верхную сторону — и позволяет отслеживать внутренние релизы.
Тут главное определиться — что из себя представляет номер версии и зачем он нужен. А там через единицу он растет или нет — это не важно.
Мне кажется, что на покупателей нашей игрушки действует именно четвертая цифра. У конкурентов она с выходом новых версий сбрасывается в 0 (?), что не отображает реальное количество изменений по сравнению с предыдущей версией. Что-то стоящее с одной попытки сделать не реально. У нас это видно
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
