Прошу прощения, был невнимателен (у меня конец рабочего дня). Код Embox к вашему проекту конечно не имеет отношения.
Но в остальном моя позиция та же — я хочу понятный, уже известный, максимально прозрачный язык для написания конфигов. QML под это определение попадает.
Знаете, честно — синтаксис языка «Ни Ява, ни мясо».
Почему я скорее всего не буду пользоваться такой системой?
Я не хочу разбираться в еще одном языке. Поэтому лично я не люблю make и qmake.
Именно за понятный, интуитивный язык, не велосипедный, я полюбил QBS.
Сейчас все руки не доходят написать продолжение статьи, воюю с разработчиками насчёт патчей…
Еще одна проблема — исходники. С qbs я скачал, и в течение пары часов разобрался как внедрить нужные фичи. Код превосходно структурирован, как QtCreator например. Читать одно удовольствие.
Такого же удовольствия от чтения, например
Оффтопик: сегодня сон мне снился, как будто я в каком-то обсуждении на Хабре учавствую, ну сон же, что программистам не снится, но единственное что в память врезалось, комментарии можно было редактировать (до первого голоса кажется). Вот уж действительно, фантастика.
PS надеюсь что вещий.
Depends для этого сделали. И нужно version.h добавить в список файлов проекта. Тогда ок будет. у меня похожая фигня была) вроде работает, но я наматюгался пока все настроил)
Спасибо, хоть кто-то в теме. Кстати, могу добавить что в правила для сборки можно написать свой небольшой парсер текстовых файлов (например, для кодогенерации), для небольших проверок на JavaScript. Например для автоматической замены версий или копирайтов.
из «коробки» уже сейчас:
-С/с++, .h файлы
-генерация и сборка moc (автоматом)
-qrc файлы
-rc файлы для msvc
-генерация pch, внедрение манифестов для msvc
-почти полная поддержка всех qt модулей.
как я уже писал, мне удалось модуль сборки для DELPHI 2007 написать. при этом без правки исходников.
для поддержки парсинга зависимостей правда пришлось еще плагин написать.
Еще довольно просто пишется модуль для кодогенератора dumpcpp.
Т.е. в теории — может всё собирать.
Кстати, хочу добавить, что если вы собираетесь присоединиться к уже существующему проекту, то мотивация остается той же самой, что в статье. Единственное, ответственности поменьше.
PS. это решение похоже на моё =).
Но в остальном моя позиция та же — я хочу понятный, уже известный, максимально прозрачный язык для написания конфигов. QML под это определение попадает.
Почему я скорее всего не буду пользоваться такой системой?
Я не хочу разбираться в еще одном языке. Поэтому лично я не люблю make и qmake.
Именно за понятный, интуитивный язык, не велосипедный, я полюбил QBS.
Сейчас все руки не доходят написать продолжение статьи, воюю с разработчиками насчёт патчей…
Еще одна проблема — исходники. С qbs я скачал, и в течение пары часов разобрался как внедрить нужные фичи. Код превосходно структурирован, как QtCreator например. Читать одно удовольствие.
Такого же удовольствия от чтения, например
уже не получишь. Такой код хорошо отлаживать только его автор, наверное. Я вот например, в ядро навряд ли патч смогу оформить.
PS надеюсь что вещий.
И мои поздравления, и ресурсу, и сообществу!
Продолжайте!
qt-project.org/wiki/Qbs_Quick_Reference
-С/с++, .h файлы
-генерация и сборка moc (автоматом)
-qrc файлы
-rc файлы для msvc
-генерация pch, внедрение манифестов для msvc
-почти полная поддержка всех qt модулей.
для поддержки парсинга зависимостей правда пришлось еще плагин написать.
Еще довольно просто пишется модуль для кодогенератора dumpcpp.
Т.е. в теории — может всё собирать.