The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Разработчики Qt представили инструментарий для сборки проектов qbs

16.02.2012 16:20

Разработчики из компании Nokia представили новый экспериментальный сборочный инструментарий qbs (Qt Build Suite), предназначенный для сборки приложений, основываясь на данных файла-проекта, все команды которого записаны на упрощенном диалекте языка QML. Файл с правилами сборки описывает только один проект, который в тоже время может содержать несколько разных программных продуктов, каждый из которых может иметь свой тип (приложение, библиотека и так далее) и отдельную схему сборки. Код qbs открыт под лицензией LGPL.

Использование упрощённой версии QML для оформления файлов с правилами сборки с одной стороны упрощает обеспечение поддержки в интегрированных средах разработки, а с другой позволяет реализовать нестандартные шаги, интегрируя в файл сборки функции, реализованные на языке JavaScript, а также подключая внешние модули. Например, в qbs можно создавать свои дополнительные правила, позволяющие задействовать дополнительные генераторы кода и компиляторы ресурсов, для трансформации файлов из одного типа в другой. Исходя из данного высокоуровневого описания в проектном файле, qbs генерирует корректный и очень подробный граф всех зависимостей проекта. В отличии от qmake, - qbs жестко не привязан к Qt и может использоваться для организации сборки любых программных продуктов.

Главное же отличие qbs в том, что классические makefile-генераторы, такие как qmake или CMake, создают лишь makefile’ы, оставляя непосредственно процесс сборки на откуп таких инструментов, как make или ninja. В отличие от данной схемы, qbs берёт на себя и роль утилиты make, без посредников напрямую запуская компиляторы, линковщики или другие инструменты сборки, такие как SCons или Ant. Сборка осуществляется в режиме параллельного выполнения нескольких сборочных потоков. Qbs изначально видит весь проект целиком, без необходимости поиска дополнительных сборочных файлов в поддиректориях, что позволяет в сочетании с техникой инкрементальной сборки достигнуть высокой производительности, заметно опережающей стандартную утилиту make. Например, для проекта из 200 библиотек, по 50 C++ классов в каждой, повторная пересборка, в ситуации когда с прошлой сборки не внесено изменений, занимает в qbs 0.843 сек., а при использовании make более 4 секунд.

Отмечается, что по сравнению с такими пакетами, как CMake и GNU Autotools, в qbs пока мало возможностей для организации полноценной кросс-платформенной сборки, учитывающей многочисленные нюансы различных программных окружений. Поэтому qbs пока невозможно использовать для серьёзных проектов в качестве полноценного аналога CMake и GNU Autotools. Тем не менее, подчеркивается, что qbs ещё на начальной стадии развития и воспринимать его следует пока только как экспериментальный проект.

Пример простого сборочного файла helloworld.qbp:


    import qbs.base 1.0
 
    Application {
        name: "HelloWorld"
        files: "main.cpp"
        Depends { name: "cpp" }
    }

Более сложный пример, с импортом вспомогательной функции planetsCorrectlyAligned из файла helpers.js.


    import qbs.base 1.0
    import "helpers.js" as Helpers

    Product {
        name: "myproject"
        Group {
            condition: Helpers.planetsCorrectlyAligned()
            file: "magic_hack.cpp"
        }
    }


  1. Главная ссылка к новости (http://labs.qt.nokia.com/2012/...)
  2. OpenNews: Разработчики из компании Google открыли код системы сборки Ninja
Автор новости: Igor Savchuk
Тип: Программы
Ключевые слова: qbs, make, cmake, poject
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (33) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.4, yurkis (ok), 18:00, 16/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Мне не очевидно чем (кроме модного ныне JS) эта штука лучше CMake/SCons
     
     
  • 2.5, Аноним (-), 18:42, 16/02/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    второй абзац новости
     
     
  • 3.13, yurkis (ok), 20:14, 16/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Отработка дерева зависимостей быстрее на 4с? Проект должен быть ну ОООЧЕНЬ большим чтобы почуствовать разницу. Для инкрементально сборки "в стиле Eclipse" только... Но кто этим пользуется? Многопоточность (кто сказал make -j3)?

    Может тогда расширяемость за счет скриптов? Так тут до SCons еще пилить и пилить.

    Я конечно люблу Qt, но тут мне не очевидно.

     
     
  • 4.23, Sauron (??), 23:19, 16/02/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    qml вообще-то by design жутко удобен для подобных задач. Опять же это только кажется, что на нем только гуй удобно делать, он вполне пригоден и для выполнения других задач.
     
     
  • 5.28, arisu (ok), 11:20, 17/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Опять же это только кажется, что на нем только гуй удобно делать

    …а на самом деле неудобно даже это.

     

  • 1.7, lucentcode (ok), 19:01, 16/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Хорошее начинание. Когда разовьют немного, будет очень удобно пользоваться. А пока Make - наше всё, ну и Ant иногда.
     
  • 1.9, Аноним (-), 19:08, 16/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не внимательно читаем? Скорость сборки выше, гибкость для каких-то магических действий сборки
     
     
  • 2.21, Sauron (??), 23:14, 16/02/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это вообще разные уровни для начала.
     

  • 1.20, добрый дядя (?), 23:13, 16/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    очень люблю QMake, а теперь уже что-то более языко-независимое выплывает - я только рад
     
  • 1.22, Sauron (??), 23:18, 16/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Такс, а что мешало qmake и раньше использовать для сборки обычных C++/C приложений? Я так частенько делал и все прекрасно работало и собиралось :)
    Просто нигде не афишируется, что qmake можно и не для Qtшных прог использовать, да и собрать qmake отдельно от Qt тот ещё процесс, хотя он тоже в принципе способен без установленных Qt работать, нужны только mkspecs'ы.
    Впрочем у qbs синтаксис всё равно круче и было бы клево его видеть в виде отдельного проекта.
     
     
  • 2.24, добрый дядя (?), 23:44, 16/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Такс, а что мешало qmake и раньше использовать для сборки обычных C++/C приложений?

    ничего не мешало, я давно уже qmake юзаю для любых C++ прог как нормальную беспроблемную систему сборки на разных ОСях

    а qbs судя по всему позволит еще и Java и прочие проекты собирать чтоб может стать весьма приятным и универсальным средством... cmake не предлагать, юзайте его сами если считаете нужным, а простые мелкие прожки в конторках - qbs

     
     
  • 3.30, green (??), 12:22, 17/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    qmake - очень слабенькая система сборки посравнению с аналогами. Если проект подвязан только к Qt + ещё простые библиотеки то недостатки неощутимы, кроме одного - это out-of-source-tree builds.
    Но вот когда юзать qmake с другими фреймворками - boost, ACE и тд - то начинаюися проблемы.
    Вобщем в этом случаие CMake выше на голову - но недостаток в том что он сложнее + дополнительная зависимость
     
     
  • 4.32, annulen (?), 13:26, 17/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >кроме одного - это out-of-source-tree builds

    qmake давно это умеет, только реализовано немного кривовато (каталог сборки не может находиться внутри каталоги с исходниками)

     
     
  • 5.33, green (??), 13:35, 17/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Да знаю о таком функционале. Но снова таки слабенько. Сборка происходет в папке с исходными файлами и надо задавать флаги qmake или явно прописывать в pro файле - это менее удобто чем то как это реализовано в CMake
     
  • 4.36, arisu (ok), 14:32, 17/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > out-of-source-tree builds.

    кстати, а зачем? вот у меня jam, например, складывает объектники в спецкаталог, равно как и бинари, и библиотеки; в рабочих каталогах с исходниками не гадит вообще, если сильно не попросить. вот я ним уж сколько лет пользуюсь и не могу понять восторгов по поводу oostb. только и радости, что скрипты усложняют.

     

  • 1.27, arisu (ok), 11:18, 17/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    из долгих обсуждений в их бложеге я в своё время так и не понял, чем им не понравился jam (в любой из его инкарнаций). ну, кроме обычного Фатального Недостатка.

    зато не требует никаких кусков Qt, собирается любым си-компилятором, имеет вполне себе turing-complete язык, умеет рассматривать проект в куче каталогов как одно целое, умеет сканировать исходники на предмет include и кэшировать это… вдобавок лицензия почти что public domain, с включением в любой проект проблем нет.

    в общем, моя не понимать. моя использовать модифицированый jam для проектов как в пару строк, так и для больших комплексов с кучей независимых библиотек, опций сборки и так далее. параллелится, работает реактивно, генерит документацию и разные данные. дёшево, удобно, сердито.

    p.s. прошу не путать с boost.jam: это мутант, больной овердизайном, как и сам буст.

     
     
  • 2.55, Аноним (-), 01:14, 22/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    представь что у нас есть человек который освоил js и qml и написал программу, а тут бац за пять минут он понял как её собрать с помощью qbs.. и когда ему понадобится добавлять сложную логику он просто напишет её на явоскрипте а не на языке системы сборки.
     
     
  • 3.56, arisu (ok), 01:15, 22/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > освоил js и qml
    > написал программу

    неа. не получается.

     

  • 1.31, annulen (?), 13:25, 17/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Используйте Premake. Декларативный синтаксис еще более лаконичен, плюс поддержка существующих IDE и независимость инструмента от Qt

    http://industriousone.com/premake
    http://industriousone.com/topic/full-stack-qt-based-development-premake-avail
    download
    http://wiki.qt-project.org/Qt_Creator/Plugins/PremakeProjectManager

     
     
  • 2.37, arisu (ok), 14:39, 17/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Используйте Premake

    а ты бы почитал причины, по которым «генераторы makefile-сов» были забракованы, что ли. сам по себе premake хорош, но вот формой не подходит.

     
     
  • 3.38, annulen (?), 16:24, 17/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Если ты про пункт "Build directly from tool", то он полон взаимоисключающих параграфов. Во-первых, идет речь про вызовы CMake изнутри мейкфалов, чем Premake не грешит, да и вообще генерация мейкфайлов сама по себе не предполагает этой антифичи. (Для каких-то кастомных шагов это может быть допустимо, но CMake делает из этого систему) Во-вторых, далее следует фраза "Waf is better in this respect, but both lack a proper set of backends for project generations (Vcproj, XCode, Makefiles etc).".

    Вобщем, на мой взгляд, реальные причины - "не JavaScript" и "не наши имена в копирайтах".

     
     
  • 4.39, arisu (ok), 17:40, 17/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Если ты про пункт "Build directly from tool"

    нет, я про то, что make не видит проект, раскиданый по каталогам, как одно целое. уж кто только не ругался на рекурсивные вызовы make в подкаталогах. это пытаются полечить костылями разной степени уродливости, но нафэйхоа? намного проще не использовать make.

     
     
  • 5.40, annulen (ok), 17:51, 17/02/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Совершенно бессмысленный аргумент. В той статье написано, что рекурсивный мейк не нужен. Так генерите нерекурсивные мейкфалы, и будет вам Щастье. Нет, блин, все пытаются свой мейк для этого написать.

    Из всех проектов по замене мейка внимания заслуживает только ninja.

     
     
  • 6.41, arisu (ok), 17:55, 17/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Совершенно бессмысленный аргумент.

    это туда, в нокию.

    > В той статье написано, что рекурсивный мейк не нужен.

    им осталось сделать ещё жажок и убрать слово «рекурсивный».

    > Нет, блин, все пытаются свой мейк для этого написать.

    далеко не только для этого, сия фича — просто вкусный бонус.

    > Из всех проектов по замене мейка внимания заслуживает только ninja.

    у make обнаружился Фатальный Недостаток, ага. это я намекаю, что «замена make» не нужна, равно как и сам make. а нинзя — это не пришей системе шлейф какой-то.

     
     
  • 7.42, annulen (ok), 18:11, 17/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Интересная логическая цепочка: "рекурсиный мейк не нужен" - "так не используй его через ж^W^W рекурсивно" - "да наплевать, все равно мейк не нужен".
     
     
  • 8.44, arisu (ok), 19:09, 17/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    вообще-то 171 make не нужен 187 8212 это моя аксиома понятно, что отсда ... текст свёрнут, показать
     
  • 7.43, annulen (ok), 18:18, 17/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    У ninja цель совершенно четкая - отделить построение DAG целей сборки и их выполнение от любых "конфигурационных" действий, чем страдает мейк. Конфигуратор делает свою работу, а нинзя - свою.


     
     
  • 8.45, arisu (ok), 19:12, 17/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    это мы уже проходили, autocrap называется для больших проектов конфигуратор мож... текст свёрнут, показать
     
  • 5.47, Michael Shigorin (ok), 19:31, 17/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > нет, я про то, что make не видит проект, раскиданый по каталогам,
    > как одно целое. уж кто только не ругался на рекурсивные вызовы
    > make в подкаталогах.

    Виденная критика была местами крива сама по себе.  Впрочем, обстоятельно сейчас не расскажу.

     
     
  • 6.48, arisu (ok), 19:43, 17/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Виденная критика была местами крива сама по себе.  Впрочем, обстоятельно сейчас
    > не расскажу.

    ну, кое-как, с матами и воплями оно костылится.

    так же, как костылится просчёт зависимостей (уж простейшие-то include система может и сама просканировать, я что, дятел — долбить ей это или костыли дёргать?).

    а уж про «проект — это все *.c в каталоге исходников» (опять же, с просчётом зависимостей и ты пы)… не, не будем о грустном.

    тот же Jam делает подобное несколькими строками. и вообще мал, реактивен (в плане скорости), удобен. для проектов среднего уровня можно его использовать и как конфигуратор заодно. да-да, я фанат jam'а, если кто ещё не заметил. и ниасилятор всего остального.

     
     
  • 7.50, annulen (ok), 20:08, 17/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Просчет зависимостей делает компилятор и генерерует .d файлы, достаточно его об это попросить. Костылить ничего не надо, достаточно использовать в мейкфайлах инклуды вместо рекурсивных вызовов.
     
     
  • 8.52, arisu (ok), 20:20, 17/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    это неудобно, хотя и точнее, чем можно сделать в билд-системе и медленней, кста... текст свёрнут, показать
     
  • 2.57, Аноним (-), 01:16, 22/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Используйте Premake. Декларативный синтаксис еще более лаконичен, плюс поддержка существующих
    > IDE и независимость инструмента от Qt
    > http://industriousone.com/premake
    > http://industriousone.com/topic/full-stack-qt-based-development-premake-avail
    > download
    > http://wiki.qt-project.org/Qt_Creator/Plugins/PremakeProjectManager

    замержить бы их идеи с вашими..

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру