Разработчики из компании Nokia представили (http://labs.qt.nokia.com/2012/02/15/introducing-qbs/) новый экспериментальный сборочный инструментарий qbs (http://chaos.troll.no/~dmolkent/qbs-0.1/) (Qt Build Suite), предназначенный для сборки приложений, основываясь на данных файла-проекта, все команды которого записаны на упрощенном диалекте языка QML (http://en.wikipedia.org/wiki/QML). Файл с правилами сборки описывает только один проект, который в тоже время может содержать несколько разных программных продуктов, каждый из которых может иметь свой тип (приложение, библиотека и так далее) и отдельную схему сборки. Код qbs открыт (http://qt.gitorious.org/qt-labs/qbs) под лицензией LGPL.Использование упрощённой версии QML для оформления файлов с правилами сборки с одной стороны упрощает интеграцию с интегрированными средами разработки, а с другой позволяет реализовать нестандартные шаги, интегрируя в файл сборки функции, реализованные на языке JavaScript, а также подключая внешние ...
URL: http://labs.qt.nokia.com/2012/02/15/introducing-qbs/
Новость: https://www.opennet.ru/opennews/art.shtml?num=33102
Мне не очевидно чем (кроме модного ныне JS) эта штука лучше CMake/SCons
второй абзац новости
Отработка дерева зависимостей быстрее на 4с? Проект должен быть ну ОООЧЕНЬ большим чтобы почуствовать разницу. Для инкрементально сборки "в стиле Eclipse" только... Но кто этим пользуется? Многопоточность (кто сказал make -j3)?Может тогда расширяемость за счет скриптов? Так тут до SCons еще пилить и пилить.
Я конечно люблу Qt, но тут мне не очевидно.
qml вообще-то by design жутко удобен для подобных задач. Опять же это только кажется, что на нем только гуй удобно делать, он вполне пригоден и для выполнения других задач.
> Опять же это только кажется, что на нем только гуй удобно делать…а на самом деле неудобно даже это.
Хорошее начинание. Когда разовьют немного, будет очень удобно пользоваться. А пока Make - наше всё, ну и Ant иногда.
Не внимательно читаем? Скорость сборки выше, гибкость для каких-то магических действий сборки
Это вообще разные уровни для начала.
очень люблю QMake, а теперь уже что-то более языко-независимое выплывает - я только рад
Такс, а что мешало qmake и раньше использовать для сборки обычных C++/C приложений? Я так частенько делал и все прекрасно работало и собиралось :)
Просто нигде не афишируется, что qmake можно и не для Qtшных прог использовать, да и собрать qmake отдельно от Qt тот ещё процесс, хотя он тоже в принципе способен без установленных Qt работать, нужны только mkspecs'ы.
Впрочем у qbs синтаксис всё равно круче и было бы клево его видеть в виде отдельного проекта.
> Такс, а что мешало qmake и раньше использовать для сборки обычных C++/C приложений?ничего не мешало, я давно уже qmake юзаю для любых C++ прог как нормальную беспроблемную систему сборки на разных ОСях
а qbs судя по всему позволит еще и Java и прочие проекты собирать чтоб может стать весьма приятным и универсальным средством... cmake не предлагать, юзайте его сами если считаете нужным, а простые мелкие прожки в конторках - qbs
qmake - очень слабенькая система сборки посравнению с аналогами. Если проект подвязан только к Qt + ещё простые библиотеки то недостатки неощутимы, кроме одного - это out-of-source-tree builds.
Но вот когда юзать qmake с другими фреймворками - boost, ACE и тд - то начинаюися проблемы.
Вобщем в этом случаие CMake выше на голову - но недостаток в том что он сложнее + дополнительная зависимость
>кроме одного - это out-of-source-tree buildsqmake давно это умеет, только реализовано немного кривовато (каталог сборки не может находиться внутри каталоги с исходниками)
Да знаю о таком функционале. Но снова таки слабенько. Сборка происходет в папке с исходными файлами и надо задавать флаги qmake или явно прописывать в pro файле - это менее удобто чем то как это реализовано в CMake
> out-of-source-tree builds.кстати, а зачем? вот у меня jam, например, складывает объектники в спецкаталог, равно как и бинари, и библиотеки; в рабочих каталогах с исходниками не гадит вообще, если сильно не попросить. вот я ним уж сколько лет пользуюсь и не могу понять восторгов по поводу oostb. только и радости, что скрипты усложняют.
из долгих обсуждений в их бложеге я в своё время так и не понял, чем им не понравился jam (в любой из его инкарнаций). ну, кроме обычного Фатального Недостатка.зато не требует никаких кусков Qt, собирается любым си-компилятором, имеет вполне себе turing-complete язык, умеет рассматривать проект в куче каталогов как одно целое, умеет сканировать исходники на предмет include и кэшировать это… вдобавок лицензия почти что public domain, с включением в любой проект проблем нет.
в общем, моя не понимать. моя использовать модифицированый jam для проектов как в пару строк, так и для больших комплексов с кучей независимых библиотек, опций сборки и так далее. параллелится, работает реактивно, генерит документацию и разные данные. дёшево, удобно, сердито.
p.s. прошу не путать с boost.jam: это мутант, больной овердизайном, как и сам буст.
представь что у нас есть человек который освоил js и qml и написал программу, а тут бац за пять минут он понял как её собрать с помощью qbs.. и когда ему понадобится добавлять сложную логику он просто напишет её на явоскрипте а не на языке системы сборки.
> освоил js и qml
> написал программунеа. не получается.
Используйте Premake. Декларативный синтаксис еще более лаконичен, плюс поддержка существующих IDE и независимость инструмента от Qthttp://industriousone.com/premake
http://industriousone.com/topic/full-stack-qt-based-developm...-
download
http://wiki.qt-project.org/Qt_Creator/Plugins/PremakeProject...
> Используйте Premakeа ты бы почитал причины, по которым «генераторы makefile-сов» были забракованы, что ли. сам по себе premake хорош, но вот формой не подходит.
Если ты про пункт "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" и "не наши имена в копирайтах".
> Если ты про пункт "Build directly from tool"нет, я про то, что make не видит проект, раскиданый по каталогам, как одно целое. уж кто только не ругался на рекурсивные вызовы make в подкаталогах. это пытаются полечить костылями разной степени уродливости, но нафэйхоа? намного проще не использовать make.
Совершенно бессмысленный аргумент. В той статье написано, что рекурсивный мейк не нужен. Так генерите нерекурсивные мейкфалы, и будет вам Щастье. Нет, блин, все пытаются свой мейк для этого написать.Из всех проектов по замене мейка внимания заслуживает только ninja.
> Совершенно бессмысленный аргумент.это туда, в нокию.
> В той статье написано, что рекурсивный мейк не нужен.
им осталось сделать ещё жажок и убрать слово «рекурсивный».
> Нет, блин, все пытаются свой мейк для этого написать.
далеко не только для этого, сия фича — просто вкусный бонус.
> Из всех проектов по замене мейка внимания заслуживает только ninja.
у make обнаружился Фатальный Недостаток, ага. это я намекаю, что «замена make» не нужна, равно как и сам make. а нинзя — это не пришей системе шлейф какой-то.
Интересная логическая цепочка: "рекурсиный мейк не нужен" - "так не используй его через ж^W^W рекурсивно" - "да наплевать, все равно мейк не нужен".
> Интересная логическая цепочка: «рекурсиный мейк не нужен» — "так не используй его
> через ж^W^W рекурсивно" — «да наплевать, все равно мейк не нужен».вообще-то «make не нужен» — это моя аксиома. понятно, что отсда следует, что не нужен никакой.
У ninja цель совершенно четкая - отделить построение DAG целей сборки и их выполнение от любых "конфигурационных" действий, чем страдает мейк. Конфигуратор делает свою работу, а нинзя - свою.
> У ninja цель совершенно четкая — отделить построение DAG целей сборки и
> их выполнение от любых «конфигурационных» действий, чем страдает мейк. Конфигуратор делает
> свою работу, а нинзя — свою.это мы уже проходили, autocrap называется. для больших проектов конфигуратор может генерить что угодно вообще, а для средних и мелких лучше иметь возможность обойтись одним инструментом. впрочем, если кто-то не может жить без конфигураторов (которые иногда больше, чем исходники всего проекта), то кто я такой, чтобы запрещать?
> нет, я про то, что make не видит проект, раскиданый по каталогам,
> как одно целое. уж кто только не ругался на рекурсивные вызовы
> make в подкаталогах.Виденная критика была местами крива сама по себе. Впрочем, обстоятельно сейчас не расскажу.
> Виденная критика была местами крива сама по себе. Впрочем, обстоятельно сейчас
> не расскажу.ну, кое-как, с матами и воплями оно костылится.
так же, как костылится просчёт зависимостей (уж простейшие-то include система может и сама просканировать, я что, дятел — долбить ей это или костыли дёргать?).
а уж про «проект — это все *.c в каталоге исходников» (опять же, с просчётом зависимостей и ты пы)… не, не будем о грустном.
тот же Jam делает подобное несколькими строками. и вообще мал, реактивен (в плане скорости), удобен. для проектов среднего уровня можно его использовать и как конфигуратор заодно. да-да, я фанат jam'а, если кто ещё не заметил. и ниасилятор всего остального.
Просчет зависимостей делает компилятор и генерерует .d файлы, достаточно его об это попросить. Костылить ничего не надо, достаточно использовать в мейкфайлах инклуды вместо рекурсивных вызовов.
> Просчет зависимостей делает компилятор и генерерует .d файлыэто неудобно, хотя и точнее, чем можно сделать в билд-системе. и медленней, кстати.
помимо прочего, на свете есть не только два языка и один компилятор.
> Костылить ничего не надо, достаточно использовать в мейкфайлах инклуды вместо
> рекурсивных вызовов.недостаточно, если я хочу, например, разные значения переменных для разных каталогов (или вообще для разных целей в одном). не то, чтобы этого совсем нельзя было сделать, но… нененене, только за большие деньги.
ну право, это бессмысленный спор: не предназначен make для ручного написания, если более-менее сложный проект собираешь. да, мэйкфайлы можно генерировать — но не проще ли тогда сделать ещё один логичный шаг и обучить генератор оставшимся функциям? ещё раз ткну пальцем в сторону jam, как весьма неплохой реализации билд-системы.
да, кстати: за табуляторы отдельный плевок. я понимаю, что «нечаянно получилось», но от этого оно приятней не становится.
> Используйте Premake. Декларативный синтаксис еще более лаконичен, плюс поддержка существующих
> IDE и независимость инструмента от Qt
> http://industriousone.com/premake
> http://industriousone.com/topic/full-stack-qt-based-developm...-
> download
> http://wiki.qt-project.org/Qt_Creator/Plugins/PremakeProject...замержить бы их идеи с вашими..