Comments on TDelphi: будни Delphi блоггера: Lazy Delphi Builder 1.4.0.175

Спасибо за отчёт. Да, действительно, всё содержим...

2011-09-01T17:47:41.556+03:00

Спасибо за отчёт.

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

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

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

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

Глюки при сканировании папок с сетевыми путями. Ук...

2011-09-01T17:15:07.909+03:00

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

>1) А для старших версий Delphi (2009, 2010, XE...

2011-04-21T17:00:21.051+03:00

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

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

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

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

Константин, спасибо за развёрнутый комментарий и п...

2011-04-21T15:36:56.366+03:00

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

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

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

Кстати, вот существует такая загвоздка. У меня ес...

2011-04-21T11:32:39.215+03:00

Кстати, вот существует такая загвоздка.

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

2011-04-14T11:07:36.255+03:00

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

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

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

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

"А по умолчанию в Delphi нет отдельной выделе...

2011-04-14T10:55:50.566+03:00

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

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

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

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

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

Отличное IMHO. Я тоже считаю, что место должно быт...

2011-04-14T09:43:49.772+03:00

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

"оставлять dcu в папке с исходниками или в де...

2011-04-14T08:51:03.215+03:00

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

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