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

Комментарии 46

А что так сложно-то? MSBuild всегда идет с .net framework и лежит он в определенном месте. Тут %systemroot%\microsoft.net\framework\v3.5\msbuild для framework 3.5. Я против добавления лишнего в PATH, если можно обойтись без этого. Внутри RAD студии есть файл rsvars.bat и там прописаны все переменные окружения нужные для сборки проектов delphi. Сам же каталог RAD Studio добавляется в PATH.
Таким образом, чтобы собрать приложение делаем так:
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 года прошло, однако.

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

Я просто напоминаю на случай если "просто из головы вылетело", надеясь, что ничего более серьёзного не случилось (а то жизнь сейчас такая пошла...).

Мы уже несколько лет собираем проекты под GitLab CI, для сборки используем скрипты Apache ANT. Там нет ничего сложного, по сути — GitLab CI Runner просто выкачивает исходники в темповую папку и запускает скрипт ant. Но это может быт и MSBuild при желании.

как у вас устроено версионирование при этом?
есть ли "релизы"? ночные/тестовые сборки? как версионируются(нумеруются) они? как, например, потом отличить бинарник тестовой сборки от релизной?

У нас в корне проекта лежит файл version, в котором прописывается номер версии продукта, которую надо собрать.
Файл 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), чтобы можно было достоверно установить из каких исходников собраны бинарники...


Если интересно, то конкретный код могу показать вечером.

Показывайте! может, кто-то захочет сделать так же )


Номер версии я предпочитаю устанавливать вручную, а вот установку номера релиза можно и автоматизировать.

Мы предпочли выпуск релиза делать по нажатию кнопки )

Покажите конкретный код, пусть он тут будет, пожалуйста
1. Уже 20 лет как собираем через стандартный make (и dcc соответствующий — под нужную платформу). И даже Delphi ставить не нужно :), легко переключаемся между версиями библиотек

2. res файл (а соответственно номер версии и все остальное), создается из rc-файла, И это возможность тоже была всегда — пользуйтесь. А так как в svn есть простая возмость проставить номер ревизии (с помощью утилиты SubWCRev), то всегда точно знаешь из каких исходников был собран файл.

  1. Уже 20 лет как собираем через стандартный make

Меня вот это и смущает обычно )), что на современных Delphi-проектах могут использоваться технологии такой давности )))


  1. res файл (а соответственно номер версии и все остальное), создается из rc-файла, И это возможность тоже была всегда — пользуйтесь.

Спасибо )) только я не хочу шаблонизировать его руками )) я хочу подправить, например, Version Info только в файле проекта — и нигде больше ))


А так как в svn есть простая возмость проставить номер ревизии (с помощью утилиты SubWCRev), то всегда точно знаешь из каких исходников был собран файл.

Я уже 10 лет не использую SVN (в своих/рабочих проектах), заменил его Git-ом… выше я упомянул, что commit revision/id тоже можно включать в Version Info )

Считаю, статье с данной темой давно пора была появиться. Мне тема знакома не по наслышке, поэтому поделюсь своим опытом по теме статьи. Имею значительный перечень проектов, которые регулярно возникает потребность собирать. Использовать project groups среды разработки оказалось не удобным. Например, чтобы собрать 1,2 и 5й проeкт потребуется создание одной project group, для 2 и 3 и 5 – другой, и т.д. Группы, к тому же, нужно как-то называть.
Для начала, я бы сформулировал задачи, которые ставит разработчик при компиляции ряда проэктов (РП).
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-файлов, за что автору выражаю своё уважение. Хотелось бы услышать от разработчиков, кто и с какими задачами, сложностями сталкивается в процессе сборки приложений и какое находят решение?

Спасибо за оценку )


  1. Происходит ли сборка РП без ошибок. Хорошо бы, например, понять, последние внесённые изменения в общие модули – не нарушили ли собираемость всех про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 )

Спасибо, Алексей. Жду статью про отладку и WinDbg, всё никак руки не дойдут разобраться самому, как на той картинке с квадратными колёсами.
В целом неплохо.
Действительно в современных 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, она это почти победила).
А у нас используется WANT
Он сам на Delphi написан, и если возможностей не будет хватать, всегда можно допилить.

с какой версией Delphi? 7? :)
Про Want — знаю, сам его во времена D7 использовал и допиливал (кстати, самый starred репозиторий у меня )))) ...

В данный момент — RIO :). Want, естественно, пиленный.

ой, мамочки! )

Всегда настраивал и производил компиляцию в среде. Познавательно. Спасибо.
Не пробовали упаковать RAD Studio в docker образ? Та еще боль ;( Хотелось бы найти решение как этот кусок го*** заставить работать.

нет, не было необходимости… но Эмба же пуликовала видосы у себя в канале

видел, но в свободном доступе есть только образы под линукс

Её даже на живой винде упаковать в учётную запись сборочного агента проблематично бывает.
При этом если общаться с техподдержкой то они заявляют что можно поставить на сборочный сервер чисто компилятор без IDE. Вот только нигде нет (не было лет несколько назад) как это сделать. А руками сидеть и вылавливать зависимости нет никакого желания.

если про компилятор на сервере сборок без IDE (и без реестра), то я делал, и не раз, и для разных версий Delphi, и под разные целевые платформы (Win32, Win64, Android)
что, нужна описание как это работает? (я думал о такой статье, не знаю насколько она объёмной выйдет )) там не сильно много, на самом деле)

Всеми руками за. Потому что у меня сейчас более примитивное решение и с ним скоро начнутся проблемы.
Это можно сделать как раздел в контексте статьи про CI.
DelphiAutomatedBuild.dpr (github)

{$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

У нас команда использует свою собственную систему сборки с инкрементацией версии через rc. DUnit для юнит-тестов, Hudson для регулярных сборок-тестирования.

а также, как можно использовать отладчик WinDbg, например, для поиска причин сбоя/падения приложений из-за библиотек, написанных на Delphi (ну, конечно же, как при этом интегрировать формирование необходимых для этого PDB-файлов в автосборку)


Есть в планах на ближайшее полугодие статья про то, как я ловил пару неприятных ошибок при помощи WinDbg, но для D7.

MadHacker
Это большой шаг вперёд по сравнению с Delphi 7 которая вообще не умеет генерировать .res без IDE

Эммм в каком смысле?
brcc32 и пожалуйста — res без IDE.
Эммм в каком смысле?

Исключительно в контексте сравнения группы проектов Delphi 7 — которая на самом деле make файл но включает в себя только компиляцию и то с особенностями, с msbuild сборочными проектами современных Delphi которые уже способны полностью провести сборку из исходников.
Кстати brcc часто ломается на всякой фигне, лучше использовать rc из windows sdk.
brcc ломался от .ico с большим количеством разрешений. Были и другие поломки (вроде все тоже с разными вариантами графики) но точно уже не вспомню.

присоединюсь против brcc (и за rc) ))
у нас он ломался при "французских" кавычках в Version Info, например )

Есть в планах на ближайшее полугодие статья про то, как я ловил пару неприятных ошибок при помощи WinDbg, но для D7.

как напишете, пульните, я бы хотел почитать )

В группе «Delphi Community»: t.me/DelphiCommunity добавлен опрос на тему «Какие версии Delphi Вы используете?»: t.me/DelphiCommunity/833. Приглашаю в группу а также пройти опрос
Я просто делаю вручную билд с нужными опциями и прочим, потом копирую строку компиляции снизу из раскрывающегося окошка Messages в самой Дельфе, удаляю лишние переводы строк, и это дело в запихиваю в cmd-файл, который можно вызвать по телнету через спецмонитор. Теперь любой разработчик может записать свои изменения в версиях и в терминале вызвать билд. Можно и по расписанию делать.

а если define-ы, например, поменялись? всё повторить? ) (и какая версия Delphi?)


по телнету? для чего?

А с чего у меня в проекте будут дефайны меняться? У нас не кружок начинающих «компьютерщиков», которые все проблемы лечат переустановкой Винды. Отладочные версии каждый сам себе делает, а выкладывается релизный билд. Всё уже устоялось, все дефайны прописаны годы назад. Версия 10.2
По телнету мне проще всего оказалось сделать, чтоб чел в терминале же видел, как идёт билд.
А с чего у меня в проекте будут дефайны меняться?

с того, например, что продукт, как бы, развивается? )


Версия 10.2

ну вот можно обойтись без копирования простыней ) и вставки их в телнет )...


кроме того, dcc32 — это только ж компиляция, но выпуск ПО — это не только компиляция, это подготовка ресурсов до компиляции, после — подписывание цифровой подписью, запаковка в архив, деплой/копирование на общий ресурс...


По телнету мне проще всего оказалось сделать, чтоб чел в терминале же видел, как идёт билд.

а если связь порвётся в момент сборки (хоть она и быстрая обычно) — заново запускать?


Телнет-то где? для чего? чтобы на сервере собирать, а не локально? сдаётся мне — это можно решить сервером сборок, который и логи ведёт и чтобы "чел видел, как идёт билд" (зачем?)

Ломается, как только надо перенести проект на другой компьютер. А то и просто на другой диск.

относительные пути помогли бы ЭТОЙ проблеме ) (но само такое решение — меня прям удивило ))

Относительные пути решают только часть этой проблемы.
В другом месте может оказаться сама Delphi.
Или из-за некорректно настроенного окружения первая оказавшаяся в PATH dcc может оказаться не той версии что тоже всё сломает.
Это работает только в одном строго фиксированном окружении. Любое изменение (безусловно его может не быть если у человека ровно один проект) и всё надо начинать сначала.
Но даже для такого сценария больше подошёл бы git с хуком на пуш, автозапуском скрипта и отправкой уведомления на почту по завершению.

Но кроме перечисления потенциальных проблем я ничего плохого в адрес решения сказать не могу. Все мы начинали с чего-то такого :)

ну, проблему фиксированности окружения решает система управления конфигурациями — тот же Ansible (и да, он работает и на Windows)
а запуск на таких окружениях должен делать сервер сборок… и никак не "ручками"…
тогда есть и повторяемость, и логи, и мониторинг и отчётность и т.п...

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории