Motto

В тихом саду здравомыслия
Пусть на вас постоянно падают
кокосовые орехи пробужденности.
Чогьям Трунгпа РИНПОЧЕ


Версия для мобильного


вторник, 12 апреля 2011 г.

Lazy Delphi Builder 1.4.0.175

Lazy Delphi Builder Grunge Stamp logo

Выложил 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 им ни к чему. Надо как-то упрощать работу программы, ибо она получилась сложной. Ведь даже со стиральной машиной самсунг проще разобраться, чем с этим.

История изменений

  1. Консольная версия: Теперь все ошибки должны корректно обрабатываться, в случае ошибки %ERRORLEVEL% точно будет устанавливаться в 1, более внятные сообщения.
  2. Добавлена возможность быстро запустить компиляцию во временную папку (%TEMP%), чтобы убедиться, что всё компилируется. Созданные в папке %TEMP% папки удаляются при закрытии программы. Добавлен параметр командной строки /tb для запуска такой компиляции в консольной версии. В GUI версии добавлена кнопка, для быстрого заполнения выходных папок. Настройки для временной компиляции не сохраняются в профиле. При следующем открытии диалога настроек компиляции, там снова будут значения из профиля.
  3. Добавлена проверка корректности параметров командной строки при старте программы. Если LazyDB не узнает параметр, будет показано соответствующее сообщение. Консольная версия, остановится.
  4. Добавлен параметр командной строки /by, позволяющий пропустить проверку параметров.
  5. Теперь укорачивание путей (замена абсолютных путей на относительные, если они короче и длинных имён файлов/папок на короткие) включается только если используется версия Delphi младше чем 2005. Также добавлен параметр командной строки /sp - (Short Paths) позволяющий включить/отключить этот режим независимо от версии Delphi.
  6. Исправлено: не работают кнопки в диалоге настроек параметров билда.
  7. Исправлено: Вызов Scan New Folder.. из дерева на “виртуальных” папках “Resources, Sources”.
  8. Исправлено: возможное зависание при открытии диалога Browse for Folder.
  9. В дерево с файлами добавлена возможность открыть меню проводника для выделенного узла.
  10. В дереве с файлами исправлены ошибки при работе с пунктами контекстного меню для элементов находящихся в Корзине.
  11. В режиме /verbose и /debug при старте печатается список полученных параметров командной строки. Добавлено для упрощения отладки при запуске из скриптов.
  12. Консольная версия: изменено форматирование при выводе справки.
  13. Консольная версия: добавлен параметр командной строки /ev <EnvVarName=Value[;EnvVar2=Valu2]>. Ключ /ev предназначен для подмены значения переменной окружения. Работает как с переменными, сохранёнными в профиле, так и с переменными Delphi, а также и системными. Подменяются только те значения, которые указаны в формате $(ИмяПеременной).
  • Всё ещё не исправлено: Некорректный парсинг настроек из .dproj файлов. Жду фикса от команды JCL.

В планах.

  • упрощение работы с программой
  • мимикрировать под дефолтное поведение Delphi при установке компонентов (оставлять dcu в папке с исходниками или в дефолтную папку Dcu out  и предлагать добавить эти папки в Library Search Path). Хотя… может и не буду этого делать.
  • работа над документацией.

9 комментариев:

  1. "оставлять dcu в папке с исходниками или в дефолтную папку Dcu out"
    Мне кажется, что не стоит хранить dcu и исходники в одной папке.
    За много лет работы с Delphi выработал для себя следующее правило раскладки файлов:
    \Packages, \Sources, \Help, ...,
    \Lib. В Lib хранятся только DCU/BPL, среда никакого доступа к Sources не имеет (пути прописаны только в Lib). На больших проектах подобная схема весьма серьезно экономит время компиляц��и.

    Впрочем, это только IMHO.

    ОтветитьУдалить
  2. Отличное 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).
    В общем, у меня пока нет видения как сделать проще и удобнее.

    ОтветитьУдалить
  3. "А по умолчанию в Delphi нет отдельной выделенной папки для Dcu файлов пользователя"
    Хмм... В Delphi 7 Projects\BPL. В остальных - не помню, я до сих пор на D7 сижу.

    "Разные наборы компонентов предлагают свои папки Lib\ВерсияDelphi и Lib\ВерсияDelphi\Debug"

    Увы - да. Поэтому я трачу энное количество времени при установке пакетов для приведения их к "моей" структуре, что вызывает смех и непонимание окружающих :)

    Мне кажется, что "идеальный вариант" - это то, что сделано в LazyDB. По-крайней мере, для меня. Думаю, что достаточно это более-менее подробно задокументировать и народ привыкнет. Ну, а кто не привыкнет - может настраивать по своему вкусу. За все время программирования и сдачи проектов, я убедился, что ты можешь заложить в проект/программу любую логику (я немного утрирую), но если это документировано, то в 90% случаев пользователи говорят: "а как-же может быть иначе".

    Кстати, мой первый пост исказился при сохранении. Я имел в виду "Package"\Sources, "Package"\LibNN и т.д. Почему угловые скобки пропали.

    ОтветитьУдалить
  4. >> А по умолчанию в Delphi нет отдельной выделенной папки для Dcu файлов пользователя"
    > Хмм... В Delphi 7 Projects\BPL

    Речь же не о BPL-ках, а о DCU-файлах. Для BPL-ок папки по умолчанию есть. А вот для dcu-файлов нет. И я кажется даже понимаю почему. Когда у человека куча проектов, содержащих файлы с именами unit1, unit2, (а ведь именно такие имена предлагает IDE по умолчанию, и именно такие имена используются в куче демок), то компиляция каждого проекта содержащего юнит с уже занятым именем будет перезаписывать тот юнит. В общем, каша будет.

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

    > Почему угловые скобки пропали.
    Blogspot режет угловые скобки в комментариях. Ничего не поделать с этим. =(

    ОтветитьУдалить
  5. Кстати, вот существует такая загвоздка.

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

    ОтветитьУдалить
  6. Константин, спасибо за развёрнутый комментарий и предложения.

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

    А у вас для всех версий 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-ом? Может что-то показалось нелогичным при использовании?

    ОтветитьУдалить
  7. >1) А для старших версий Delphi (2009, 2010, XE)
    >вы собираете?
    Пока нет. В обозримом будущем - придётся. На данный момент я вынужден поставить процесс разработки, тестирования и деплоймента, т.к. то что было до моего прихода в проекте - ад и ужас :)

    Почему nant - потому то другая группа разработчиков его уже использует, уже есть лицензии на NantBuilder, на серверах он уже проинсталлирован и пр. Я, конечно, как разработчик из мира Linux и Python хотел бы использовать waf, но как оказалось тут достаточно сложно всё. want был отсеян по причине убогой страницы и отсутствия демонстрации того, что проект активно развивается.

    Сравнений не было, было только моё субъективное мнение :) Да и по каким параметрам сравнивать - у всех трёх упомянутых xml-like конфигурация примерно одинаковая, ни одна утилита из трёх представленных не умеет в автоматическом режиме собрать и проинсталлировать компоненту в Delphi IDE, а потому надо выбирать ту утилиту по которой можно быстро получить помощь.

    Относительно третьего пункта - я немного подумаю и напишу подробнее.

    ОтветитьУдалить
  8. Глюки при сканировании папок с сетевыми путями. Указать папку в сети и нажать Scan. Кроме папки Recycled ничего нет. И в этой папке все как то не так.

    ОтветитьУдалить
  9. Спасибо за отчёт.

    Да, действительно, всё содержимое сетевых папок считается несуществующим и попадает в мусорную корзину (Recycled).

    Я зафиксировал этот баг у себя в todo-списке.

    На данный момент могу посоветовать вариант подключать сетевую папку в виде диска:
    net use x: \\computer name\share name

    и работать в LazyDB с сетевой папкой как с локальным диском.

    ОтветитьУдалить

Постоянные читатели