Комментарии 47
Таким образом, чтобы собрать приложение делаем так:
call rsvars.bat
%systemroot%\microsoft.net\framework\v3.5\msbuild /t:Clean MyApp.dproj
%systemroot%\microsoft.net\framework\v3.5\msbuild /t:Build /p:Config=Release MyApp.dproj
Либо для пути msbuild писать %FrameworkDir%\msbuild. Переменная FrameworkDir описана в rsvars.bat
Если нужно собрать несколько программ, то оформляем project group и собираем, заменяя MyApp.dproj на ProjGroup.groupproj
Если нужны какие-то более сложные действия (условная сборка, подписывание сборок, сборка установщика, загрузка результата куда-то), то лучше сделать скрипт msbuild. Или powershell. Можно даже сделать bat файл, но это сложнее.
Задаю выходные каталоги я прямо в настройках проекта. Он нормально переживает относительные пути.
Номер версии лучше включать не через настройки проекта, а с помощью rc файла. Т.е. собирать как ресурс, а сами номера вынести в отдельный h-файл. Если интересно, то конкретный код могу показать вечером.
Номер версии я предпочитаю устанавливать вручную, а вот установку номера релиза можно и автоматизировать.
Таким образом получается проект, который можно собирать как в IDE, так и через командную строку без необходимости что-то где-то настраивать.
Точно так же сделал автодеплой через Jenkins.
Было бы интересно узнать, как ТС видит прикручивание сборки делфовских проектов к GitLab CI.
Спасибо )
Было бы интересно узнать, как ТС видит прикручивание сборки делфовских проектов к GitLab CI.
Stay tuned! )))))
4 года прошло, однако.
Конечно, написание статей - дело добровольное, автор никому ничего не обязан, даже если обещал и публично озвучивал планы - обстоятельства всякие бывают, однако.
Я просто напоминаю на случай если "просто из головы вылетело", надеясь, что ничего более серьёзного не случилось (а то жизнь сейчас такая пошла...).
как у вас устроено версионирование при этом?
есть ли "релизы"? ночные/тестовые сборки? как версионируются(нумеруются) они? как, например, потом отличить бинарник тестовой сборки от релизной?
Файл version либо руками модифицируется, когда например стартуем новую ветку продукта, либо автоматом из батника.
Процесс сборки начинается, если запушить тегированный коммит (можно руками, можно батником который инкрементирует версию и пушит на сервер коммит с тегом).
Скрипты Ant поднимают версию из файла — таким образом Ant знает какую версию собирает и куда выкладывать результат сборки. Ant генерит rc файл со всеми нужными строками и подставленной версией (так она попадает в свойства EXE/DLL), дополнительно генерится inc файл где костантами прописывается версия, название приложения, компания и т.п. для целей потом использовать в самом приложении, например выводить в лог.
GitLab крутится на одном серваке, а сборка идет на другом (под Windows).
Ночные сборки не делаем, но при каждом пуше на сервер, запускается лайтовая (без цифровых подписей, без инсталлера) сборка с юнит тестами.
MSBuild не стали использовать потому что у нас были проекты под Delphi 7, а теперь еще и Golang, C++ и т.п.
Apache Ant гибкая система, мы просто написали ряд макросов (запуск компилятора, подпись результата, сбор отладочных файлов (dbg, pdb, сборка инсталлятора и т.п.)
А что так сложно-то?
мне кажется, "сложность" лишь из-за того, что я расписал детали того, как это устроено
ничего сложного в запуске, например
msbuild /t:build DAB.ciproj /p:DCC_ExeOutput=binaries /p:FileVersion=4.3.2.1
мне не видится )
Таким образом, чтобы собрать приложение делаем так:
call rsvars.bat
%systemroot%\microsoft.net\framework\v3.5\msbuild /t:Clean MyApp.dproj
%systemroot%\microsoft.net\framework\v3.5\msbuild /t:Build /p:Config=Release MyApp.dproj
это если запускать батник… сервер сборок, который я использовал (Quickbuild) из коробки поддерживает сборку MSBuild-ом, там негде вызывать call rsvars.bat для инициализации окружения… зато можно задать переменные окружения (ту же BDS) и свойства запуска (по сути, опции /property)
, то лучше сделать скрипт msbuild. Или powershell. Можно даже сделать bat файл, но это сложнее.
Можно, но зачем батники для сборки, если есть msbuild? )) ну, батник для запуска msbuild-скрипта — ок )) но "логику"? не думаю )
Задаю выходные каталоги я прямо в настройках проекта. Он нормально переживает относительные пути.
мне кажется удобным, когда выходной каталог находится вне каталога с исходниками
так что по умолчанию они относительные (у разработчика в IDE), на сервере сборок — переопределяются ...
ну,, кроме того, я привёл пример, когда нужно собрать несколько версий одного приложения… делать несколько конфигураций? можно, но я предпочту задать другой выходной каталог...
Номер версии лучше включать не через настройки проекта, а с помощью rc файла. Т.е. собирать как ресурс, а сами номера вынести в отдельный h-файл.
Ну, в Delphi до версии 2007 я так и делал… Сейчас же мне нравится описанный способ. Кроме того, я в пример не стал включать, но там можно задавать ЛЮБЫЕ свойства, включаемые в Version Info — в частности, commit id (Git) /revision number(SVN), чтобы можно было достоверно установить из каких исходников собраны бинарники...
Если интересно, то конкретный код могу показать вечером.
Показывайте! может, кто-то захочет сделать так же )
Номер версии я предпочитаю устанавливать вручную, а вот установку номера релиза можно и автоматизировать.
Мы предпочли выпуск релиза делать по нажатию кнопки )
2. res файл (а соответственно номер версии и все остальное), создается из rc-файла, И это возможность тоже была всегда — пользуйтесь. А так как в svn есть простая возмость проставить номер ревизии (с помощью утилиты SubWCRev), то всегда точно знаешь из каких исходников был собран файл.
- Уже 20 лет как собираем через стандартный make
Меня вот это и смущает обычно )), что на современных Delphi-проектах могут использоваться технологии такой давности )))
- res файл (а соответственно номер версии и все остальное), создается из rc-файла, И это возможность тоже была всегда — пользуйтесь.
Спасибо )) только я не хочу шаблонизировать его руками )) я хочу подправить, например, Version Info только в файле проекта — и нигде больше ))
А так как в svn есть простая возмость проставить номер ревизии (с помощью утилиты SubWCRev), то всегда точно знаешь из каких исходников был собран файл.
Я уже 10 лет не использую SVN (в своих/рабочих проектах), заменил его Git-ом… выше я упомянул, что commit revision/id тоже можно включать в Version Info )
Для начала, я бы сформулировал задачи, которые ставит разработчик при компиляции ряда проэктов (РП).
1. Происходит ли сборка РП без ошибок. Хорошо бы, например, понять, последние внесённые изменения в общие модули – не нарушили ли собираемость всех проeктов. А если я поменял ..unit8.pas и unit9.pas, хорошо бы знать, каких проeктов это каснулось.
2. Возможность сборки при разных наборах условных директив
3. Моментальное получение файлов результатов сборки (EXE, APK) в заданных папках
4. Очистка/удаление результатов сборки, а также временных (debug) файлов
5. Использование RAM-диска (в общем случае – отдельной папки) для временных файлов и результатов сборки, для ускорения компиляции. Также это позволит не засорять папки с исходниками
6. Наглядность сборки. Хорошо бы видеть ряд проeктов и отметив галочками, выполнять действия по сборке, очистке и прочее, так сказать, визуально наблюдая за процессом. bat-файлы по сборке в командной строке наглядности не дадут.
Поэтому после некоторого опыта создания bat-файлов с запуском консольного компиляторока Delphi DCC32.EXE было принято решение о написании приложения MultiCompiler, которое я уже пару лет успешно использую для сборки проeктов. Матрица директив в проeктах, матрица модулей в проeктах, быстрое включение/исключение модулей в проeктах просто поставив или убрав галочку, всё это существенно облегчает и упрощает жизнь. В данный момент поддерживаются компиляторы от версии 18.0 до 33.0, соответственно, от BDS 2006 до Embarcadero Delphi 10.3. В ближайшее время появится пакетная сборка APK.
Статья оказалась интересной и детально осветившей тему, особенно описание dproj-файлов, за что автору выражаю своё уважение. Хотелось бы услышать от разработчиков, кто и с какими задачами, сложностями сталкивается в процессе сборки приложений и какое находят решение?
Спасибо за оценку )
- Происходит ли сборка РП без ошибок. Хорошо бы, например, понять, последние внесённые изменения в общие модули – не нарушили ли собираемость всех проeктов.
2,3,4,5,6...
Я возлагаю все эти задачи на сервер сборок, который после каждого пуша исходников проводит тестовую сборку проекта (хоть это самостоятельный проект, хоть это библиотека… с библиотеками — даже должно быть строже, т.к. они используются во множестве проектов на разных версиях Delphi), его тестов и их запуск…
При этом он: делает это заново в чистом каталоге (нет необходимости что-то чистить), задержка в одну-две минуты на накладные расходы по клонированию — приемлема.Она ничего не решает, по-моему )
п. 6 — для меня спорный. Я отдаю всё на откуп автоматизации. Из ручных действий — максимум — нажать кнопку "выпустить релиз" ))
В ближайшее время появится пакетная сборка APK.
Мне хотелось поделиться мыслью о том, что всё, что нынче умеет Delphi из коробки (повторюсь, начиная с версии 2007), — можно автоматизировать запуском MSBuild-а с параметром YOUR_PROJECT.dproj.
А собирать APK она умеет ))
Т.е. запустив
msbuild YOUR_FMX_PROJECT.dproj /p:Platform=Android /t:build;deploy
на выходе получим APK )
Действительно в современных Delphi используется msbuild и это уже хоть какой то сборочный стандарт, который позволяет для простых случаев отказаться от самописных сборочных скриптов.
К сожалению в приближенной к реальности ситуации всё равно не получится.
Рассмотрим тот же VersionInfo — .dproj не умеет multilang. Это большой шаг вперёд по сравнению с Delphi 7 которая вообще не умеет генерировать .res без IDE, но всё ещё не спасает от необходимости генерировать .res руками.
Возможность передать Defines в сборку — замечательно. Но вот сама Delphi уж очень ограничена в возможностях своих Define и вставить ими в исходник например дату сборки не получится. Всё равно нужна кодогенерация или патч исходников. И вот уже дополнительный шаг сборки.
Можно упомянуть про prebuild и postbuild (и вы скорее всего напишете про них в следующих статьях), но это тоже не решение всех проблем. Они имеют сильную завязку на окружение. И есть сценарии где шагами сборочного сервера решить задачу будет проще чем шагами проекта.
В целом хорошо что статьи появляются. Глобально есть очень много тёмных пятен. Например мало кто использует динамическую линковку компонентов, потому что возникают сложности с распространением нужных bpl со своим продуктом. (и это при том, что многие опенсорс компоненты по лицензии требуют именно динамическую линковку).
Мало кто понимает что такое bpl\dcu и прочие файлы генерируемые Delphi.
Не все различают файлы проекта и файлы IDE лежащие рядом с проектом и не знают чего добавить в гитигнор.
Так что буду ждать новых статей. Может увижу и для себя что-то полезное.
К сожалению в приближенной к реальности ситуации всё равно не получится.
я и не говорил, что этого достаточно, я лишь хотел обратить внимание, что кастомные сборки можно строить вокруг msbuild-скриптов, а не "батничков"
Можно упомянуть про prebuild и postbuild
признаться, не планировал ) на мой взгляд, это решение, которое провоцирует использовать IDE для сборки, что мне не нравится )
и вставить ими в исходник например дату сборки не получится
а зачем?
а если очень хочется, то можно вставить в Version Info, например… это чуть сложнее, чем просто использование hardcode-переменной "дата-сборки", но задачу может решить...
по сравнению с Delphi 7 которая вообще не умеет генерировать .res без IDE
кстати, даже D2007 не умеет )), но и это лечится custom-ным msbuild-скриптом ))
но всё ещё не спасает от необходимости генерировать .res руками.
для multilang version info?
Я правильно понимаю, что multilang version info — это когда в version info содержится несколько блоков с разными language code?
Мне кажется, и это можно кастомизировать скриптом, а не руками делать )
а зачем?
Для версий с ограниченным сроком жизни, например.
Я правильно понимаю, что multilang version info — это когда в version info содержится несколько блоков с разными language code?
Мне кажется, и это можно кастомизировать скриптом, а не руками делать )
Да, это когда в зависимости от локали ОС будет показано описание на соответствующем языке. Скриптами не получится, потому что rc генерирует расширение msbuild. Поставляемая на .net вместе с Delphi библиотека. И она просто физически не способна переварить формат отличный от того, который есть в .dproj. То есть кастомизировать скриптом будет означать всё равно генерацию rc руками и дальнейшую сборку :).
Идея использовать IDE для сборки уже почти никому не нравится. Но далеко не все вещи готовы к полноценной работе вне среды (речь не о Delphi, она это почти победила).
Он сам на Delphi написан, и если возможностей не будет хватать, всегда можно допилить.
с какой версией Delphi? 7? :)
Про Want — знаю, сам его во времена D7 использовал и допиливал (кстати, самый starred репозиторий у меня )))) ...
При этом если общаться с техподдержкой то они заявляют что можно поставить на сборочный сервер чисто компилятор без IDE. Вот только нигде нет (не было лет несколько назад) как это сделать. А руками сидеть и вылавливать зависимости нет никакого желания.
если про компилятор на сервере сборок без IDE (и без реестра), то я делал, и не раз, и для разных версий Delphi, и под разные целевые платформы (Win32, Win64, Android)
что, нужна описание как это работает? (я думал о такой статье, не знаю насколько она объёмной выйдет )) там не сильно много, на самом деле)
{$IFDEF RELEASE}
WriteLn('This is RELEASE build');
{$ENDIF RELEASE}
{$IFDEF DEBUG}
WriteLn('This is DEBUG build');
{$ENDIF DEBUG}
{$IFDEF TRIAL}
WriteLn('This is TRIAL version');
{$ENDIF DEBUG} // {$ENDIF TRIAL} копипаст, будь он неладен
WriteLn('This file version is ', GetFileVersion);
Для мобильных приложений на Delphi, подозреваю, всё сложнее
для Android — не прям уж )
как уже упоминал:
msbuild YOUR_FMX_PROJECT.dproj /p:Platform=Android /t:build;deployвсё
для iOS (кроме симулятора) я не собирал, так что в деталях не подскажу, но, вроде, достаточно подключённой OSX
а также, как можно использовать отладчик WinDbg, например, для поиска причин сбоя/падения приложений из-за библиотек, написанных на Delphi (ну, конечно же, как при этом интегрировать формирование необходимых для этого PDB-файлов в автосборку)
Есть в планах на ближайшее полугодие статья про то, как я ловил пару неприятных ошибок при помощи WinDbg, но для D7.
MadHacker
Это большой шаг вперёд по сравнению с Delphi 7 которая вообще не умеет генерировать .res без IDE
Эммм в каком смысле?
brcc32 и пожалуйста — res без IDE.
Эммм в каком смысле?
Исключительно в контексте сравнения группы проектов Delphi 7 — которая на самом деле make файл но включает в себя только компиляцию и то с особенностями, с msbuild сборочными проектами современных Delphi которые уже способны полностью провести сборку из исходников.
Кстати brcc часто ломается на всякой фигне, лучше использовать rc из windows sdk.
brcc ломался от .ico с большим количеством разрешений. Были и другие поломки (вроде все тоже с разными вариантами графики) но точно уже не вспомню.
Есть в планах на ближайшее полугодие статья про то, как я ловил пару неприятных ошибок при помощи WinDbg, но для D7.
как напишете, пульните, я бы хотел почитать )
а если define-ы, например, поменялись? всё повторить? ) (и какая версия Delphi?)
по телнету? для чего?
По телнету мне проще всего оказалось сделать, чтоб чел в терминале же видел, как идёт билд.
А с чего у меня в проекте будут дефайны меняться?
с того, например, что продукт, как бы, развивается? )
Версия 10.2
ну вот можно обойтись без копирования простыней ) и вставки их в телнет )...
кроме того, dcc32 — это только ж компиляция, но выпуск ПО — это не только компиляция, это подготовка ресурсов до компиляции, после — подписывание цифровой подписью, запаковка в архив, деплой/копирование на общий ресурс...
По телнету мне проще всего оказалось сделать, чтоб чел в терминале же видел, как идёт билд.
а если связь порвётся в момент сборки (хоть она и быстрая обычно) — заново запускать?
Телнет-то где? для чего? чтобы на сервере собирать, а не локально? сдаётся мне — это можно решить сервером сборок, который и логи ведёт и чтобы "чел видел, как идёт билд" (зачем?)
относительные пути помогли бы ЭТОЙ проблеме ) (но само такое решение — меня прям удивило ))
В другом месте может оказаться сама Delphi.
Или из-за некорректно настроенного окружения первая оказавшаяся в PATH dcc может оказаться не той версии что тоже всё сломает.
Это работает только в одном строго фиксированном окружении. Любое изменение (безусловно его может не быть если у человека ровно один проект) и всё надо начинать сначала.
Но даже для такого сценария больше подошёл бы git с хуком на пуш, автозапуском скрипта и отправкой уведомления на почту по завершению.
Но кроме перечисления потенциальных проблем я ничего плохого в адрес решения сказать не могу. Все мы начинали с чего-то такого :)
Та-дам! Проект скомпилировался
Вот так и смотри статьи из прошлого) BDS установлен, однако:
error MSB4057: в проекте нет целевого объекта "build"
Куды его добавить, что писать... непонятно)
Автоматизированная сборка Delphi-приложения