Выложил Lazy Delphi Builder 1.4.0.175. Скачивать на домашней странице: www.LazyProject.info. На всякий случай, есть зеркало на Google Code. Об ошибках сообщать здесь или на почту/скайп, в комментариях к посту, или в Issues на Google Code.
Из забавного. Все, кому я показывал плакат опубликованный в предыдущем посте, отметили что на логотипе изображён античный храм болтающийся на висилице. =))) Так вот. И на самом деле там изображён подъёмный кран!
Пару слов о проекте, для тех кто забыл. Lazy Delphi Builder задумывался как инструмент для упрощения сборки проектов/компонентов. Он просканирует папки, найдёт там все нужные файлы. Предложит выбрать что собирать, а что нет. Позволит указать параметры сборки, и папки куда складывать полученные файлы. Соберёт всё, как надо и даже скопирует все файлы ресурсов в одну папку. А также сохранит все выбранные файлы с настройками на диске, и сможет запустить его позже. Умеет подменять часть путей переменными. Хранит настройки в текстовом файле.
Всю прошлую неделю работал над проектом ежедневно по несколько часов в день. Вылизывал работу консольной версии и делал режим быстрой компиляции. В самом конце сделал возможность подменять значения Environment variables из командной строки. Над инструкцией поработать не успел.
Работы над проектом уйма. И в первую очередь работы над упрощением программы. С одной стороны Lazy Delphi Builder позволяет собрать все файлы (и dcu, и даже ресурсы) в указанных пользователям папках. А с другой, почти никто из опрошенных мной программистов не видит в этом нужды. =) А те, кто видят, предпочитают ручками вызывать dcc32.exe с нужными параметрами и LazyDB им ни к чему. Надо как-то упрощать работу программы, ибо она получилась сложной. Ведь даже со стиральной машиной самсунг проще разобраться, чем с этим.
История изменений
- Консольная версия: Теперь все ошибки должны корректно обрабатываться, в случае ошибки %ERRORLEVEL% точно будет устанавливаться в 1, более внятные сообщения.
- Добавлена возможность быстро запустить компиляцию во временную папку (%TEMP%), чтобы убедиться, что всё компилируется. Созданные в папке %TEMP% папки удаляются при закрытии программы. Добавлен параметр командной строки /tb для запуска такой компиляции в консольной версии. В GUI версии добавлена кнопка, для быстрого заполнения выходных папок. Настройки для временной компиляции не сохраняются в профиле. При следующем открытии диалога настроек компиляции, там снова будут значения из профиля.
- Добавлена проверка корректности параметров командной строки при старте программы. Если LazyDB не узнает параметр, будет показано соответствующее сообщение. Консольная версия, остановится.
- Добавлен параметр командной строки /by, позволяющий пропустить проверку параметров.
- Теперь укорачивание путей (замена абсолютных путей на относительные, если они короче и длинных имён файлов/папок на короткие) включается только если используется версия Delphi младше чем 2005. Также добавлен параметр командной строки /sp - (Short Paths) позволяющий включить/отключить этот режим независимо от версии Delphi.
- Исправлено: не работают кнопки в диалоге настроек параметров билда.
- Исправлено: Вызов Scan New Folder.. из дерева на “виртуальных” папках “Resources, Sources”.
- Исправлено: возможное зависание при открытии диалога Browse for Folder.
- В дерево с файлами добавлена возможность открыть меню проводника для выделенного узла.
- В дереве с файлами исправлены ошибки при работе с пунктами контекстного меню для элементов находящихся в Корзине.
- В режиме /verbose и /debug при старте печатается список полученных параметров командной строки. Добавлено для упрощения отладки при запуске из скриптов.
- Консольная версия: изменено форматирование при выводе справки.
- Консольная версия: добавлен параметр командной строки /ev <EnvVarName=Value[;EnvVar2=Valu2]>. Ключ /ev предназначен для подмены значения переменной окружения. Работает как с переменными, сохранёнными в профиле, так и с переменными Delphi, а также и системными. Подменяются только те значения, которые указаны в формате $(ИмяПеременной).
- Всё ещё не исправлено: Некорректный парсинг настроек из .dproj файлов. Жду фикса от команды JCL.
В планах.
- упрощение работы с программой
- мимикрировать под дефолтное поведение Delphi при установке компонентов (оставлять dcu в папке с исходниками или в дефолтную папку Dcu out и предлагать добавить эти папки в Library Search Path). Хотя… может и не буду этого делать.
- работа над документацией.
"оставлять dcu в папке с исходниками или в дефолтную папку Dcu out"
ОтветитьУдалитьМне кажется, что не стоит хранить dcu и исходники в одной папке.
За много лет работы с Delphi выработал для себя следующее правило раскладки файлов:
\Packages, \Sources, \Help, ...,
\Lib. В Lib хранятся только DCU/BPL, среда никакого доступа к Sources не имеет (пути прописаны только в Lib). На больших проектах подобная схема весьма серьезно экономит время компиляции.
Впрочем, это только IMHO.
Отличное IMHO. Я тоже считаю, что место должно быть настроено.
ОтветитьУдалитьУ меня все dcu-файлы тоже хранятся в отдельной папке. Точнее, у меня есть одна общая папка для всех dcu-шек.
Точнее даже у меня для каждой версии Delphi есть общая папка Build и в ней подпапки: Bin, Dcp, Bpl, Dcu, DebugDCU и Res.
Я писал здесь о том, какую иерархию папок предпочитаю использовать.
Все эти папки включены в Library Path. В принципе, только они и включены.
И Delphi и все проекты настроены так, чтобы все выходные файлы попадали только в эти папки.
Изначально Lazy Delphi Builder был заточен именно под такую организацию рабочего места.
Но.. большинство опрошенных мной программистов не сильно заморачиваются с настройкой рабочего места, оставляя настройки по умолчанию. А по умолчанию в Delphi нет отдельной выделенной папки для Dcu файлов пользователя. Разные наборы компонентов предлагают свои папки Lib\ВерсияDelphi и Lib\ВерсияDelphi\Debug. Идеального варианта я пока не вижу.
Сейчас для работы с LazyDB пользователю необходимо указать хоть какую-то папку для Dcu файлов. И многие юзеры, часто спрашивают, что туда вписывать и зачем. Отсюда и пришла идея дать возможность ничего не указывать и оставлять dcu файлы где придётся (ведь LazyDB игнорирует .cfg файлы, а с недавнего времени и опционально игнорирует и настройки в .dof, .bdsproj, .dproj).
В общем, у меня пока нет видения как сделать проще и удобнее.
"А по умолчанию в Delphi нет отдельной выделенной папки для Dcu файлов пользователя"
ОтветитьУдалитьХмм... В Delphi 7 Projects\BPL. В остальных - не помню, я до сих пор на D7 сижу.
"Разные наборы компонентов предлагают свои папки Lib\ВерсияDelphi и Lib\ВерсияDelphi\Debug"
Увы - да. Поэтому я трачу энное количество времени при установке пакетов для приведения их к "моей" структуре, что вызывает смех и непонимание окружающих :)
Мне кажется, что "идеальный вариант" - это то, что сделано в LazyDB. По-крайней мере, для меня. Думаю, что достаточно это более-менее подробно задокументировать и народ привыкнет. Ну, а кто не привыкнет - может настраивать по своему вкусу. За все время программирования и сдачи проектов, я убедился, что ты можешь заложить в проект/программу любую логику (я немного утрирую), но если это документировано, то в 90% случаев пользователи говорят: "а как-же может быть иначе".
Кстати, мой первый пост исказился при сохранении. Я имел в виду "Package"\Sources, "Package"\LibNN и т.д. Почему угловые скобки пропали.
>> А по умолчанию в Delphi нет отдельной выделенной папки для Dcu файлов пользователя"
ОтветитьУдалить> Хмм... В Delphi 7 Projects\BPL
Речь же не о BPL-ках, а о DCU-файлах. Для BPL-ок папки по умолчанию есть. А вот для dcu-файлов нет. И я кажется даже понимаю почему. Когда у человека куча проектов, содержащих файлы с именами unit1, unit2, (а ведь именно такие имена предлагает IDE по умолчанию, и именно такие имена используются в куче демок), то компиляция каждого проекта содержащего юнит с уже занятым именем будет перезаписывать тот юнит. В общем, каша будет.
Но всё-равно вариант, о котором я писал в предыдущем комментарии меня пока устраивает больше всего. Надо будет ещё только к LazyDB приделать отслеживание случаев, когда создаваемые dcu-файлы перезаписывают существующие, и вообще будет удобно.
> Почему угловые скобки пропали.
Blogspot режет угловые скобки в комментариях. Ничего не поделать с этим. =(
Кстати, вот существует такая загвоздка.
ОтветитьУдалитьУ меня есть проект, который по определенным причинам тестируется и собирается разными версиями Delphi (5,6 и 7) под разными ОС. Сборка осуществляется nant-ом и один из этапов в ней - генерация exe-файла при помощи вызова Lazy Delphi Builder с заранее созданным профилем.
nant-овский скрипт висит в системе контроля версией и всё с ним хорошо, но вот добавить профиль Lazy Delphi Builder (LDB) я не могу, т.к. если в профиле не указано какой версией Delphi собирать, то он (LDB) автоматически прекращает процесс. Иметь же несколько профилей под разные версии дельфи, отличающиеся только одной строчкой - довольно неудобно и накладно, не говоря уже о том, что мне придется менять скрипт сборки, настройки тестировочных серверов, чтобы они запускали правильную цель сборки и т.д.
Потому предложение таково: если в профиле не указана версия Delphi и на машине установлена единственная версия, то подгружать нужно настройки и пути из нее и попытаться собрать проект.
В идеале - завести некоторый глобальный профиль, куда будут сохранятся дефолтные настройки, а далее настройки из глобального профиля перекрываются настройками из текущего профиля, если в текущем профиле настройка опущена, то она извлекается из глобального профиля.
Также в идеале хотелось бы какого-нибудь механизма применения настроек по директориям: например, в директорию ложится профиль с некоей настройкой, которая будет перекрывать настройку в глобальном профиле и будет использоваться для всех профилей в этой директории и вложенных. Т.е. появляется дополнительное место откуда могут браться настройки.
Касательно тех же версией Delphi, применяемых при сборке, это могло бы выглядеть так. Клон репозитария в папку C:\Projects\D6 и дальнейшая сборка приводила бы к сборке посредством Delphi 6, а клон этого же репозитария в C:\Projects\D7 -- посредством Delphi 7 (есстественно в обеих директориях лежат скрытые(?) файлы с соотв. указаниями)
Константин, спасибо за развёрнутый комментарий и предложения.
ОтветитьУдалить> Иметь же несколько профилей под разные версии дельфи, отличающиеся только одной строчкой - довольно неудобно и накладно.
А у вас для всех версий Delphi используется один и тот же файл проекта (dpk или dpr)?
Потому как в случае с компонентами, все библиотеки обычно содержат отдельный .dpk файл на каждую версию Delphi, и в этих случаях профили будут отличаться более чем одной строчкой. Об этом случае я тоже думал, но так и не придумал, как это лучше сделать. Пока вижу только 2 варианта:
1) Ввести в LazyDB, условные Environment variables, меняющие значение в зависимости от выбранной версии Delphi
2) Ввести поддержку условий (а ля {$IFDEF}) для групп файлов, в том числе и с возможностью указывать, какие файлы будут использоваться для какой версии Delphi. Пока склоняюсь к нему.
И тот и другой вариант пока представляются довольно сложными в реализации и в использовании. Поэтому, пока что для таких случаев надо использовать 2 отдельных профиля.
Впрочем, для случая когда компилируются один и тот же проект разными версиями, я последую вашему предложению, да. =)
> предложение таково: если в профиле не указана версия Delphi и на машине установлена единственная версия, то подгружать нужно настройки и пути из нее и попытаться собрать проект.
Я думал о том, чтобы указывать какую версию Delphi использовать в командной строке. Как-то так: "/D 7", "/D 12", "/D 15". И добавлю параметр "/D Any", позволяющий использовать первую попавшуюся версию. В случае, если версия Delphi не указана в профиле недоступна, будет использоваться режим "/D Any".
А вот поддержку перекрывающих друг-друга профилей с разными приоритетами я делать не буду. Потому что отследить потом, какие настройки откуда берутся будет делом сложным и запутанным. Что-то похожее, вроде уже реализовано для dcc32 (файлы Проект.cfg и .dof), которые, кстати игнорируются при сборке Lazy Delphi Builder-ом, именно для того, чтобы быть уверенным, что всё собирается с одинаковыми настройками.
Но я обещаю подумать об этой идее.
И если не сложно, ответьте пожалуйста на пару вопросов:
1) А для старших версий Delphi (2009, 2010, XE) вы собираете? Мне просто интересно, можно ли обойтись для этих целей сочетанием nant-а и msbuild. Если есть такой опыт, поделитесь пожалуйста.
2) Почему именно nant (а не скажем want, или ant)? Проводились ли какие-то сравнения?
3) Сложно было разобраться с Lazy Delphi Builder-ом? Может что-то показалось нелогичным при использовании?
>1) А для старших версий Delphi (2009, 2010, XE)
ОтветитьУдалить>вы собираете?
Пока нет. В обозримом будущем - придётся. На данный момент я вынужден поставить процесс разработки, тестирования и деплоймента, т.к. то что было до моего прихода в проекте - ад и ужас :)
Почему nant - потому то другая группа разработчиков его уже использует, уже есть лицензии на NantBuilder, на серверах он уже проинсталлирован и пр. Я, конечно, как разработчик из мира Linux и Python хотел бы использовать waf, но как оказалось тут достаточно сложно всё. want был отсеян по причине убогой страницы и отсутствия демонстрации того, что проект активно развивается.
Сравнений не было, было только моё субъективное мнение :) Да и по каким параметрам сравнивать - у всех трёх упомянутых xml-like конфигурация примерно одинаковая, ни одна утилита из трёх представленных не умеет в автоматическом режиме собрать и проинсталлировать компоненту в Delphi IDE, а потому надо выбирать ту утилиту по которой можно быстро получить помощь.
Относительно третьего пункта - я немного подумаю и напишу подробнее.
Глюки при сканировании папок с сетевыми путями. Указать папку в сети и нажать Scan. Кроме папки Recycled ничего нет. И в этой папке все как то не так.
ОтветитьУдалитьСпасибо за отчёт.
ОтветитьУдалитьДа, действительно, всё содержимое сетевых папок считается несуществующим и попадает в мусорную корзину (Recycled).
Я зафиксировал этот баг у себя в todo-списке.
На данный момент могу посоветовать вариант подключать сетевую папку в виде диска:
net use x: \\computer name\share name
и работать в LazyDB с сетевой папкой как с локальным диском.