qbs 1.2.0

можно подготовить IDL-файл

Зачем это нужно?

это для фанатов CORBA, видимо

Для Ice, Thrift, Protocol Buffers и т.д. В контексте новости, думаю, IDL надо понимать как класс языков.

оно не генерирует ninja файлы, а значит ненужно.

для dbus, например

Насколько я понял, QBS тянет в зависимостях часть Qt5, что как бы жирновато для системы сборки.

А что ты еще хотел от Qt Build Suite?

Процитирую текст новости:

В отличие от qmake, qbs не привязан к Qt и изначально рассчитан на организацию сборки любых проектов.

Ну, все верно, qbs может собрать обычный c++ без qt. Но это не значит, что он сам не требует qt.

И чем оно лучше того же cmake'а, кроме похожести на JSON?

И чем оно лучше того же cmake'а, кроме похожести на JSON?

cmake == костыль для маке, а qbs сам все вызывает.

Ну и за синтаксис ты сам сказал

С моей Т.З. это не является плюсами.
Какая мне разница, транслируется ЯВУ сразу в машкоды или через ассемблер.
Как у qbs сделана работа с поиском внешних библиотек?
А то в cmake приходится совмещать find_package и pkg_check_modules

говорят, там со сборкой с qt с любой сложностью проекта вообще проблем нету. Также, например, гораздо легче портировать сборку с qt4 на qt5.

В линупсе, где уже есть Qt5? Не очень. В макоси и венде жирное ПО это норма.

С моей Т.З. это не является плюсами.

Но это потенциально ускоряет сборку проекта, если qbs годно разруливает кэши и зависимости, конечно, чего с помощью make'а добиться сложно, если вообще возможно.

http://blog.qt.digia.com/blog/2012/02/15/introducing-qbs/

Судя по интро, он лучше справляется со сборкой кода с минимум изменений. Хотя мелочь разумеется.

Как у qbs сделана работа с поиском внешних библиотек?

Если я не ошибаюсь, он может в pkg-config помимо всего прочего.

m0rph
Насколько я понял, QBS тянет в зависимостях часть Qt5, что как бы жирновато для системы сборки.
http://download.qt-project.org/official_releases/qbs/1.2.0/
8.9M

Совсем даже не жирно.

Если я не ошибаюсь, он может в pkg-config помимо всего прочего.

Интересно, явно, как cmake, или не явно?
Но вообще уже неплохо.
Кстати, если копались, а он тянет только qt-core или ещё много чего?
Потому что не всегда есть возможность сборки той же qt-gui, т.к. иксы не доступны.

Но это потенциально ускоряет сборку проекта, если qbs годно разруливает кэши и зависимости, конечно, чего с помощью make'а добиться сложно, если вообще возможно.

Ну это скорее дополнительная плюшка, чем киллер фича, хотя кому как.
Лично мне время сборки не особо критично, т.к. не KDE ваяю.

там со сборкой с qt

У меня проекты не qt-шные ни разу, так что сугубо параллельно.

cmake == костыль для маке, а qbs сам все вызывает.

если это инструмент уровня cmake и более прозрачный сам по себе, это тем более заслуживает внимания

Интересно, явно, как cmake, или не явно?

Я не знаю, как в cmake. В qbs вызывается бинарник pkg-config и парсится выхлоп.

Кстати, если копались, а он тянет только qt-core или ещё много чего?

Как минимум:

QT += script gui

Наверняка что-то еще.

Лично мне время сборки не особо критично, т.к. не KDE ваяю.

Ну, для hello world'ов можно и вовсе без систем сборки, напрямую g++ ...

если qbs годно разруливает кэши и зависимости

Что значит годно? CMake сканирует includes в файлах и строит зависимости, это «годно»?

Там стоит «если», что как бы намекает, что я не очень в курсе.

В интро тащем-то написано почему он работает быстрее make'а:

Qbs sees the project as whole and thus does not need to fork itself for subdirectories. Even if only a part of the project is built, the whole build graph is taken into consideration. The problems of recursive make (see [RMCH]) are no more.

This also has the consequence that incremental builds are much faster than with make.

Ну, для hello world'ов

Ну, если научный софт это hello world'ы, то Ок.

Я не знаю, как в cmake. В qbs вызывается бинарник pkg-config и парсится выхлоп.

Вопрос был, как в проекте прописывается.
В cmake необходимо напрямую указывать директиву pkg_check_modules, при этом имея find_package.
Т.е. в тексте одновременно встречались find_package(some_cool_lib) и pkg_check_modules(another_cool_lib), использующий pkg-config, только потому, что не ко всем либам есть cmake'овские модули.
Если в этом qbs сделано что-то подобное, то нафиг не надо.
Если же они прозрачно для пользователя делают, то хорошо.

QT += script gui

Значить жёппа. Не пойдёт.

Если в этом qbs сделано что-то подобное

Насколько я понимаю, что-то подобное сделано. Имеются Probe модули, которые реализуют pkg-config и прочие, и нужно вручную указывать нужные тебе Probe'ы. Но никто не мешает написать мета-зонд, который перебирает возможные варианты.

Народ, а кто в курсе, как у сабжа дела с кросбилдами?

QBS тянет в зависимостях часть Qt5

Система сборки нужна программистам, мейнтейнерам и гентушникам. Остальных это никак не трогает. Да и к тому же это где-то 8-9 мегабайт.

cmake == костыль для маке, а qbs сам все вызывает.

Дык, cmake может генерировать файлы для всяких IDE. QBS этого не умеет и не будет?

все в описании офигительно, кроме зависимости от qt. вангую, что для сборки non-qt проектов никто это использовать не захочет.

QBS этого не умеет и не будет?

Напиши плагин и будет уметь

cmake == костыль для маке, а qbs сам все вызывает.
Ну и за синтаксис ты сам сказал

Почему только для make? Cmake умеет генерировать и ninja-файлы и проекты для различных IDE, например XCode и MSVC.

оно не генерирует ninja файлы, а значит ненужно.

Печально, если так. Сейчас перевёл рабочий проект с обычных Makefile на CMake + Ninja. Около сотни мелких подпроектов, 2500 исходников на C/C++. Конфигурация + генерация ninja 6 секунд. Старт сборки (с проверкой всех зависимосей) доли секунды, считай мгновенно. И, конечно же, никаких явных зависимостей в самих проектах, они разруливаются автоматически и обновляются на лету.

Кто-нибудь пробовал QBS в реальности на больших проектах? Он вообще поддерживает генерацию в бекенд, типа Makefile, Ninja, Tup? Или пытается делать всё сам, как Ant, Scons?

В интро тащем-то написано почему он работает быстрее make'а:

Сделали аналог директории сборки в CMake. С генератором вроде Ninja, когда один build.ninja в корне на все подпроекты. Это хорошо.

А как у QBS с интеграцией разных директорий сборки? К примеру, в CMake для этого есть функция export().

cmake == генератор => ему не нужно ничего самому вызывать.

Напиши плагин и будет уметь

Зачем мне это?

Ну и если qbs не умеет такое, то в этом принципиальная разница.

Кто-нибудь пробовал QBS в реальности на больших проектах?

Сам Qt Creator собирается с помощью qbs (опционально, конечно).

Он вообще поддерживает генерацию в бекенд, типа Makefile, Ninja, Tup?

Нет.

Зачем мне это?

Это опенсорц, детка!

У кого болит - тот и чешет.

У кого болит - тот и чешет.

Я вообще-то просто поинтересовался может ли _для_меня_ qbs заменить, довольно кривоватый, цмейк. Всё-таки штука новая, могли учесть ошибки других. Ответ получил, а дальше «заболело» что-то похоже у тебя.

Ну и чисто чтобы поспорить - написание плагинов и опенсорс понятия ортогональные.