Пару слів про проект, для тих хто забув. Lazy Delphi Builder замислювався як інструмент для спрощення збірки проектів / компонентів. Він просканує папки, знайде там всі потрібні файли. Запропонує вибрати що збирати, а що ні. Дозволить вказати параметри збірки, і папки куди складати отримані файли. Збере все, як треба і навіть скопіює всі файли ресурсів в одну папку. А також збереже всі вибрані файли з настройками на диску, і зможе запустити його пізніше. Вміє підміняти частину шляхів змінними. Зберігає настройки в текстовому файлі.
Весь минулий тиждень працював над проектом щодня по кілька годин на день. Вилизував роботу консольної версії і робив режим швидкої компіляції. В самому кінці зробив можливість підміняти значення Environment variables з командного рядка. Над інструкцією попрацювати не встиг.
Роботи над проектом сила-силенна. І в першу чергу роботи над спрощенням програми. З одного боку Lazy Delphi Builder дозволяє зібрати всі файли (і dcu, і навіть ресурси) в зазначених користувачам папках. А з іншого, майже ніхто з опитаних мною програмістів не бачить в цьому потреби. =) А ті, хто бачать, вважають за краще ручками викликати dcc32.exe з потрібними параметрами і LazyDB їм ні до чого. Треба якось спрощувати роботу програми, бо вона вийшла складною. Адже навіть з пральною машиною сумісного простіше розібратися, чим з цим.
Історія змін
- спрощення роботи з програмою
- мімікрувати під дефолтний поведінку 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. В принципі, тільки вони і включені.
Спочатку 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 за замовчуванням, і саме такі імена використовуються в купі демок), то компіляція кожного проекту містить юніт з уже зайнятим ім'ям буде перезаписувати той юніт. Загалом, каша буде.
До речі, ось існує така заковика.
У мене є проект, який з певних причин тестується і збирається різними версіями 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) Ввести підтримку умов (а ля) для груп файлів, в тому числі і з можливістю вказувати, які файли будуть використовуватися для якої версії Delphi. Поки схиляюся до нього.
І той і інший варіант поки представляються досить складними в реалізації і в використанні. Тому, поки що для таких випадків треба використовувати 2 окремих профілю.
Втім, для випадку коли компілюються один і той же проект різними версіями, я піду вашої пропозиції, так. =)
> Пропозиція така: якщо в профілі не зазначена версія Delphi і на машині встановлена єдина версія, то довантажувати потрібно налаштування і шляхи виходу з неї і спробувати зібрати проект.
Я думав про те, щоб вказувати яку версію Delphi використовувати в командному рядку. Якось так: "/ D 7", "/ D 12", "/ D 15". І додам параметр "/ D Any", що дозволяє використовувати першу-ліпшу версію. У разі, якщо версія Delphi не зазначена в профілі недоступна, буде використовуватися режим "/ D Any".
А ось підтримку перекривають один-одного профілів з різними пріоритетами я робити не буду. Тому що відстежити потім, які налаштування звідки беруться буде справою складною і заплутаною. Щось схоже, на зразок вже реалізовано для dcc32 (файли Проект.cfg і .dof), які, до речі ігноруються при складанні Lazy Delphi Builder-му, саме для того, щоб бути впевненим, що все збирається з однаковими настройками.
Але я обіцяю подумати про цю ідею.
Чому nant - тому то інша група розробників його вже використовує, вже є ліцензії на NantBuilder, на серверах він уже змонтували та ін. Я, звичайно, як розробник зі світу Linux і Python хотів би використовувати waf, але як виявилося тут досить складно все. want його відсіяли через убогій сторінки і відсутності демонстрації того, що проект активно розвивається.
Порівнянь не було, було тільки моя суб'єктивна думка :) Та й за якими параметрами порівнювати - у всіх трьох згаданих xml-like конфігурація приблизно однакова, жодна утиліта з трьох представлених не вміє в автоматичному режимі зібрати і проинсталлировать компоненту в Delphi IDE, а тому треба вибирати ту утиліту по якій можна швидко отримати допомогу.
Щодо третього пункту - я трохи подумаю і напишу докладніше.