Pull to refresh

Comments 49

Интересная вещь, особенно учитывая подключаемые модули. Раньше в этом плане мне нравился малоизвестный bam, но теперь хочется попробовать QBS :-)
Штука действительно занимательная. Вот сейчас только закончил разбираться с написанием плагинов и ковырянием кода для поддержки сканирования по маске, надо будет рассказать потом)
Вот почему всегда в качестве примера приводится сборка какого нибудь «Hello World» (не только для данной системы справедливо, для make, cmake тоже самое)? Нет чтобы взять проэктик с парой модулей там, с более ли менее сложной организацией, детально показать какие преимущества дает для крупных проектов.
Пока главное преимущество — скорость. По сравнению с nmake — более чем в два раза. Какая принципиально разница будет если я вместо сборки 2х приложений вставлю 10?
А вот насчет более сложных либ, с наследованием и прочими вкусностями согласен. Просто не стал раздувать статью для первой публикации.
Если хочется монструозный примерище, я дал ссылку — исходники Qt Creator. Там куча qbs модулей, со сложными скриптами. Работает. Я с их помощью и разбирался в хитросплетениях.
Ух наконец кто-то решился одолеть эту проблему. Я уж боялся, что придется ковыряться и изучать синтаксис всех этих make/cmake/qmake (так как под nix* ничего серьезного не пишу, но иногда бывает необходимо).
Пока QBS не выйдет на стадию альфы хотя бы, вам все равно придется изучать синтаксис «всех этих». Ну и тем более библиотеки вроде буста вряд ли на него перейдут даже в отдалённом будущем.
А кто их знает. На самом деле зависимостей у QBS совсем чуть чуть, они сами сказали, что будут приветствовать сторонние проекты, это будет не как вещь в себе типа qmake.
Великолепно, что любимая библиотека развивается в разных направлениях!
Выглядит просто офигительно. Такой простой синтаксис — просто сказка какая-то.
Ох, жду не дождусь когда он зарелизится… Прямо мечта!
А за статью спасибо =)
Пожалуйста, приятно получить одобрение, буду писать ещё, о продвинутом использовании!
Вот интересно было бы не просто «продвинутое использование», а в сравнении с qmake: создать .pro и .qbs файлы для сборки одного и того же сложного проекта, чтоб наглядно продемонстрировать преимущества новой системы.
Хм, не думал о таком, спасибо за идею. Принимаю. А пока можете сравнить pro и qbs файлы в исходниках QtCreator, как я уже упоминал. На мой взгляд, ЧИТАЕМЕЕ на порядок.
Молодцы! Надеюсь что эта технология станет общепринятой.
От make-файлов давно пора отказаться… иногда приходится сталкиваться с программированием под Linux, не понимаю как такая дикая смесь какого-то древнего бейсика и не менее древнего командного процессора могла так долго просуществовать.
Очевидно же, «работает — не трогай». Других причин просто не вижу. :}
Дело, скорее, в совместимости.
Хм, точно. Совсем забыл.
«Жертвуйте производительностью ради совместимости», или как-то так. На память пишу, и не помню где читал. Что-то вроде юникс-вея? Кто напомнит.
Согласен, здоровый консерватизм и инертность в таких фундаментальных вещах, как система сборки, иногда не лишние.
Но и мучаться от ущербного дизайна тоже вечно нельзя. Надо переходить… и qbs предлагает отнюдь не эволюционный метод.
UFO just landed and posted this here
UFO just landed and posted this here
qbs именно так и сделан. Он не привязан ни к чему. Можно свои парсеры для поддержки pas файлов сделать к примеру.
UFO just landed and posted this here
UFO just landed and posted this here
В QBS парсер на си пишется для поиска зависимостей файлов, например для *.c, *.cpp, *.mm файлов ищутся #include директивы, по которым становится понятно от каких header'ов он зависит, чтобы в нужный момент послать его на пересборку
Вся остальная логика (какие указать флаги для компилятора, линковщика и т.п.) реализована уже в QBS модулях (в qml стиле)
Спасибо, хоть кто-то в теме. Кстати, могу добавить что в правила для сборки можно написать свой небольшой парсер текстовых файлов (например, для кодогенерации), для небольших проверок на JavaScript. Например для автоматической замены версий или копирайтов.
Да, это возможно) Довольно занятная штука
К слову, игрался с QBS пару месяцев назад, пофиксил там ряд багов, но обломился из-за одного момента — QBS тогда не умел подхватывать в качестве инклудов сгенерированные хидеры из другого продукта, не подскажешь — это уже пофиксили или нет? (На тот момент собирались делать что-то странное с этим, но я так и не понял по рассылке — что именно)
ну я прикрутил dumcpp он генерирует h и cpp. Работает вроде. Может я конкретную вашу цель не понял.
Если быть конкретнее:
а) есть библиотека libboo, она генерирует version.h;
б) есть приложение foo, среди его артефактов есть goo.cpp, который содержит #include <boo/version.h>.
Вопрос — как их подружить? Если:
а) на момент скана version.h еще не существует;
б) поиск хидеров идет только среди глобальных мест (типа /usr/include) и артефактов данного продукта. (Построитель графа зависимостей даже не пытается искать version.h среди артефактов проекта libboo).
В итоге возможна ситуация, когда goo.o будет пытаться скомпилировать до того, как сгенерируется version.h
Depends для этого сделали. И нужно version.h добавить в список файлов проекта. Тогда ок будет. у меня похожая фигня была) вроде работает, но я наматюгался пока все настроил)
Не подскажешь как именно? Просто это единственное, что мне помешало сборку кутима до конца на qbs перевести (за исключением поиска внешних зависимостей, но это легче довести до ума)
Отлично, спасибо.

Такой вот вопрос хочу задать, я смотрю все свойства задаются строками.
Т.е. не используются какие-либо перечисления допустимых типов, а именно строки:
«cpp», «application» и т. д.

А как система отреагирует на некорректное значение, опечатку и т. д?
в случае с типом сборки — проигнорирует, если у вас не настроены специальные цели. application, «staticlibrary» — это не зашитые типы, они настраиваются в модулях.
cpp — скажет что нет такого свойства (модуля).
Свойства не обязательно строками — можно любые допустимые в JS. главное чтобы модуль это обработал.
я могу property variant foo: 'blah'; задать и обрабатывать его либо как строку либо как массив.
Можно объекты и тп. (в общем, смотрим доки по QML)
Почему-то еще все забывают такую важную вещь в сборке, как конфигурирование… например, как настроить include/lib paths для 3rd party библиотек. Конечно, если по старинке делать как в make, т.е. писать/генерить через configure.sh, но уже не 1999 год. Такие вещи должны включаться в систему сборки, как must have.
Для этого и разработана система модулей. В модуль включается процедура конфигурирования.
Сейчас правда проще через глобальный конфиг все фигачать, нестабильный механизм какой-то =(, но в архитектуре все предусмотрено уже!
И кроме конфигурирования, в дизайне предусмотрена процедура для сборки пакетов и деплоя. Тоже будет в модулях. Просто пока нет реализации.
UFO just landed and posted this here
как я уже писал, мне удалось модуль сборки для DELPHI 2007 написать. при этом без правки исходников.
для поддержки парсинга зависимостей правда пришлось еще плагин написать.
Еще довольно просто пишется модуль для кодогенератора dumpcpp.
Т.е. в теории — может всё собирать.
Не поделитесь парсером? Интересно было бы попробовать.
из «коробки» уже сейчас:
-С/с++, .h файлы
-генерация и сборка moc (автоматом)
-qrc файлы
-rc файлы для msvc
-генерация pch, внедрение манифестов для msvc
-почти полная поддержка всех qt модулей.
Вроде слышал, что там еще можно делать нечто вроде фильтров чтобы осуществлять генерацию проектных файлов. Правда в комментах эту фичу как теоретически возможную описывали, но говорили, что если очень хочется, то можно написать генератор студийных проектов.
Судя по всему, проект заглох. Никаких серьёзных изменений за последние два месяца в проекте не было… в основном правки наподобие оптимизаций и чистки кода.
Все еще смотрю на проект с надеждой, но она тает с каждым днем. Пока продолжаю использовать те же сборочные скрипты (удобно и не нужно дополнительно ничего делать), своей модифицированной версии qbs (с возможностью сканирования директорий).
P.S. В переписке Йорг и Освальд… довольно агрессивно что ли, отнеслись к предложению каких-либо новшеств. Мне показалось слишком уж консервативно для такого молодого проекта, поэтому я плюнул на попытки ваять патчи для них. Может и зря.
Добавились Probe'ы для возможности поиска библиотек, добавились wildcard'ы, мы сумели им собрать qutIM со всеми зависимостями. Нормально они к патчам относятся.
Joerg и Oswald, так же как и другие разработчики Qt очень положительно относятся к патчам. Просто они должны быть оформлены в соответствии с правилами и соответствовать Qt Coding Style Convention.
хорошо, я неправ. Просто значит качество кода которое я предоставляю проекту, не соответствует высокому стандарту.
Просто не нужно бросать патч на полпути, а исправлять указанные недочеты.
По ссылке «сильно сложным» считают не cmake, а… autotools. Про сам же cmake сказано только то, что он требует установки доп. пакета, что правда и в случае с qbs.
Ну и опять же несправедливо забыта ninja, у которой нет поддержки IDE, но которая тоже очень быстра.
Sign up to leave a comment.

Articles