Развиваемый проектом Qt сборочный инструментарий qbs (http://qt-project.org/wiki/qbs) (Qt Build Suite) достиг (http://blog.qt.digia.com/blog/2013/05/31/qbs-1-release/) того состояния, при котором возможна удобная сборка проектов сложности уровня Qt Creator. Таким образом, проект заслуживает той версии, которая бы отражала его полезность. Для стимулирования использования qbs в других проектах, разработчики решили присвоит новому выпуску qbs знаковый номер версии 1.0.0.
Примечательной особенностью qbs является использование упрощённого варианта языка QML для определения сценариев сборки проекта, что позволяет определять достаточно гибкие правила сборки, в которых могут подключаться внешние модули, использоваться функции на JavaScript и создаваться произвольные правила сборки. При этом язык адаптирован для автоматизации генерации и разбора сценариев сборки интегрированными средами разработки. В отличии от qmake, qbs не привязан к Qt и изначально рассчитан на организацию сборки любых проектов.
Кроме того, qbs не генерирует make-файлы, а сам без посредников, таких как утилита make, контролирует запуск компиляторов и компоновщиков, оптимизируя процесс сборки на основе детального графа всех зависимостей. Наличие изначальных данных о структуре и зависимостях в проекте позволяет эффективно распараллеливать выполнение операций в несколько потоков. Для крупных проектов, состоящих из большого числа файлов и поддиректорий, производительность повторной пересборки с использованием qbs может опережать make в разы - пересборка выполняется почти мгновенно и не заставляет разработчика тратить время на ожидание.Особенности qbs:
- Позволяет собирать проекты для разных платформ в той же командной оболочке (shell);
- Позволяет параллельно собирать множество конфигураций одного проекта;
- Предоставляет быстрые инкрементальные сборки (оценки производительноти (https://blog.qt.digia.com/blog/2013/04/16/qbs-reached-mile-s.../));
- Использует QML-подобный язык;
- Поддерживается в Qt Creator 2.8;
- Не привязан к версии Qt, т.е. смена используемой версии Qt не заставляет менять версию инструментария сборки.
В анонсе отмечено, что не смотря на то, что замена основанной на qmake системы сборки Qt в принципе возможна, сборка Qt всё ещё будет требовать скрипт configure и небезызвестный syncqt. Разработчики смотрят дальше и ставят целью замену configure и syncqt на qbs, а это то место, где qbs всё ещё отстаёт.
URL: http://blog.qt.digia.com/blog/2013/05/31/qbs-1-release/
Новость: https://www.opennet.ru/opennews/art.shtml?num=37069
Чем это лучше Apache Maven?
Ждём похороникс или они таким не занимаются?
Хотя бы тем что не на жаве. Но вместе они не нужны, потому что есть cmake.
cmake то еще дерьмецо! CMakeList выглядит ужасно
Да это еще куда ни шло. А вот определение либ на платформе, свойств платформы и прочая - глюкастое донельзя. В этом плане его спокойно зарулят даже древние автотулсы.
> Да это еще куда ни шло. А вот определение либ на платформе,
> свойств платформы и прочая - глюкастое донельзя. В этом плане его
> спокойно зарулят даже древние автотулсы.Зарулят? Ну-ну. В CMake изначально решены проблемы (ну или сильно затрднены пути создания таковых) с неправильным порядком ключей -I и -L, например. Немало проектов на autotools, особенно крупных, не собирается правильно при наличии уже установленной в системе копии. В CMake такого добиться ещё надо постараться (в OpenCV 2.4, например, умудрились).
Плюс, язык CMake куда очевиднее, чем m4 или шелл.
Насчёт же определения свойств платформы - patches are welcome, разработчики весьма отзывчивы. Всё-таки проект заметно моложе autotools, поэтому не удивительно, что количество поддерживаемых платформ (и то, относительно экзотических) меньше.
> Немало проектов на autotools, особенно крупных, не собирается правильно при наличии уже
> установленной в системе копии.их авторов надо бить молотками по головам. фиче «сначала ищем несисемный инклюд в каталоге собираемого исходника» сто лет в обед. если проект при сборке инклюдит свои файлы как системные… это уже даже не прискорбно, это неоперабельно. исходники-то пропатчить можно, а как мозги авторам починить?
>> Немало проектов на autotools, особенно крупных, не собирается правильно при наличии уже
>> установленной в системе копии.
> их авторов надо бить молотками по головам. фиче «сначала ищем несисемный инклюд
> в каталоге собираемого исходника» сто лет в обед. если проект при
> сборке инклюдит свои файлы как системные… это уже даже не прискорбно,
> это неоперабельно. исходники-то пропатчить можно, а как мозги авторам починить?Хотите - верьте, хотите - нет, но вот лично я недавно получил ответ в духе "сам дурак, убери старые либы из системы и всё соберётся как надо", когда запостил в багтрекер Samba4 жалобу на такую проблему. Там, правда, сильно переделанный WAF, а не autotools, но суть та же, и очень уж пример яркий.
Причём, что самое смешное, кто-то из авторов изначального кода WAF даже оставил комментарий, мол, надо быть внимательнее с порядком опций -L - то есть вменяемые люди есть. Но со временем они куда-то деваются...
да я так, «в общем негодую». я тоже подобное встречал, и вроде бы у людей вполне нормальных.в принципе, имея на руках достаточно большой проект, в котором таких мест не одно и не два, я бы тоже ответил в духе «удали старьё и не зуди». потому что это проще, чем тратить время на занудное перепахивание кучи файлов и потом на то, чтобы это всё опять начало собираться. в теории, конечно, такой шаг самый правильный, а на практике никому это делать охоты нет.
Дык что самое-то обидное - предлагаешь патч, который решает эту проблему, а его даже смотреть не хотят. :(
> Дык что самое-то обидное - предлагаешь патч, который решает эту проблему, а
> его даже смотреть не хотят. :(а вот это уже странно.
Изень, не позорь программистов на джаве
да какой он на хрен программист?
> да какой он на хрен программист?Ну как какой? Быдлокодер обыкновенный, одна штука.
Кто тебе сказал, что он вообще кодер?
http://accelconf.web.cern.ch/accelconf/icalepcs2011/papers/w...
О..еть, по этому бреду даже статьи пишут. CERN научились бюджеты пилить, молодцы.
Что мне нравится в maven - перед компиляцией он может сам скачивать всё дерево зависимостей, причём это кроссплатформенно: под любым линуксом, виндой, макосью.Я на С++ не пишу, но как я понимаю для с++ такое нельзя:
все зависимости управляются менеджером пакетов дистрибутива, у каждого дистрибутива менеджер пакетов свой, пакеты называются по разному.
>у каждого дистрибутива менеджер пакетов свойне всё так печально, все дебиан-базированные (Ubuntu и т.п.) на dpkg, Fedora, OpenSuse - rpm, ну и плюс пару дистров, базированных на Slackware и подобных. зависимости пакетов вытягиваются командами, в самих пакетах есть эта инфа, если пакет не содержит только статически собранные программы и конфиги. такое тоже бывает. так что написать что-то в этом духе для большинства дистрибутивов - не шибко сложно. и это не является свойством какого-то языка программирования. большинство проектов просто выдают ошибку, если какой-то devel пакет доустановить надо.
> Что мне нравится в maven - перед компиляцией он может сам скачивать
> всё дерево зависимостей, причём это кроссплатформенно: под любым линуксом, виндой,
> макосью.
> Я на С++ не пишу, но как я понимаю для с++ такое
> нельзя:
> все зависимости управляются менеджером пакетов дистрибутива, у каждого дистрибутива менеджер
> пакетов свой, пакеты называются по разному.Оборотная сторона - Maven усложняет сторонний контроль процесса сборки и поэтому хорош для машины разработчика, на начальном и основном этапах разработки. Как только речь заходит о подготовке релиза - "умность" Maven, WAF, Ruby bundler и тому подобных приходится выключать, чтобы полностью контролировать среду сборки и благодаря этому иметь возможность получать стабильные результаты сборки.
авторы статьи - скорее всего просто студенты, проходившие практику в ЦЕРНе и написавшие курсач по этой теме. Очень плохо себе представляю специалиста, занятого гибридизацией мейка и мавена вместо реализации алгоритмов из вычислительной физики и математики, ну или чем они там занимаются))
> Чем это лучше Apache Maven?любая система сборки, которая не требует ставить говножабу, уже лучше. даже sh.
iZEN, а ты с плюсами используешь мавен?
Чем это лучше cmake?
> Чем это лучше cmake?Ничем, разумеется. Но наверняка лучше кривого qmake.
Хотя я прочитал статью, cmake делает makefile, а это чудо нет. Стоит его попробывать
И почитать учебник русского языка тоже не забудь.
Как ниже заметили, нет вызовов промежуточных тулзов (будь то make или что ещё), как следствие, сборка идет гораздо быстрее (все помним, что рекурсивные мейкфайлы - зло?).
Ну и возможность писать ф-ии на джаваскрипте в разы лучше синтаксиса симейка. Работа со строками в симейке - это та еще попоболь.
Вообще синтаксис симейка ужасен для системы сборки, имхо.
>все помним, что рекурсивные мейкфайлы - зло?Не помню. Почему?
>>все помним, что рекурсивные мейкфайлы - зло?
> Не помню. Почему?Потому что не позволяют построить полное и единственное дерево зависимостей на весь проект, а без такого дерева невозможно эффективно распараллелить сборку.
Сам сделал такую систему сборки, основанную на gnu make - рекурсивно зачитываются все Makefile'лы через директивы include, сроится полное дерево зависимостей и выполняется сборка: сначала параллельно собираются все исходники, потом параллельно линкуются все либы, затем также параллельно линкуются все исполняемые файлы. Достигается идеальная масштабируемость на любое количество cpu - когда при сборке все cpu загружены на 100%.
и ты посмотри в сторону jam. может понравится.
>и ты посмотри в сторону jam. может понравится.jam штука хорошая. Кстати, спасибо что в свое время "навёл" на него. Когда дерево представляет собой один проект - удобен сильно (даже при наличии богатой фантазии в части вариантов сборки). Когда дерево - это несколько проектов с пересекающимися общими частями, но которые надо собирать частично по-разному в зависимости от текущего собираемого проекта, добавляется немного трюкачества, впрочем, в конечном итоге все решаемо оказалось. Правда Jamfiles слегка потеряли свою простоту и "прозрачность", но в любом случае сложней Makefile'ов для тех же проектов все равно не стали. ))
> Кстати, спасибо что в свое время «навёл» на него.рад, что кому-то помогло.
> и ты посмотри в сторону jam. может понравится.да, интересный проект, только вызывает сомнение автоматическое построение зависимостей через рекурсивный скан хедеров.
во-первых, теряется время сборки,
во-вторых не факт, что зависимости вычисляются правильно - только компилятор (точнее препроцессор) точно знает какие хедера были подключены при компиляции. Не все компиляторы могут выдавать такую информацию - gcc может.
У себя пока зависимости от хедеров не вычисляю - мне важна скорость сборки с нуля, поэтому процесс сборки разбит на две части: генерация общих хедеров, которые могут включаться где угодно, а потом уже сборка всего остального.кстати, пример моего Makefile'а
include $(TOP)/make/make_header.mk
DLL := eventmgr
DEFINES += THREAD_COUNT=10 $(if $(filter TARGET_GATE%,$(DEFINES)),THREAD_COUNT_EXTEND=10)
INCLUDE += $(TOP)/common/sdiag
SRC := sk_pool.cpp th_pool.cpp timeserv.cpp eventmgr.cpp
DLLS := diagnose
DEFINES_WINXX := USE_WINSOCK2
USE_LINUX := pthread
USE_WINXX := ws2
USE_SOLARIS := socket
include $(TOP)/make/make_default.mk
> только вызывает сомнение автоматическое построение зависимостей
> через рекурсивный скан хедеров.пока что, за кучу лет использования в проектах разных размеров, проблем не было. разве что может лишнюю зависимость посчитать — но это не так уж страшно.
> во-первых, теряется время сборки
даже в стандартном варианте jam делает всё это *очень* быстро. но для тех, кому всё-таки медленно — есть патчик (гуглится несложно), который кэширует выхлоп сканера.
> У себя пока зависимости от хедеров не вычисляю — мне важна скорость
> сборки с нулямне, честно говоря, важна скорость сборки всегда. но важнее скорости — адекватность языка сборщика. jam мне показался намного более нормальным, нежели make. и, конечно, поддержка подкаталогов из коробки.
впрочем, я вдобавок использую сильно модифицированый Jambase. ну, то там правило добавил, то там правило поправил — так и выросло.
> кстати, пример моего Makefile'а
тоже неплохо. если постараться, make можно превратить в «почти jam». :3
>> только вызывает сомнение автоматическое построение зависимостей
>> через рекурсивный скан хедеров.
> пока что, за кучу лет использования в проектах разных размеров, проблем не
> было. разве что может лишнюю зависимость посчитать — но это не
> так уж страшно.Это, например, страшно при пакетной сборке, когда пакет, являющийся псевдо-зависимостью, удаляется во время сборки искомого. Всё-таки потребности разработчика и мэйнтейнера пакетов сильно различны, хорошая система сборки как раз та, которая пытается быть удобной в обоих случаях.
>>> только вызывает сомнение автоматическое построение зависимостей
>>> через рекурсивный скан хедеров.
>> пока что, за кучу лет использования в проектах разных размеров, проблем не
>> было. разве что может лишнюю зависимость посчитать — но это не
>> так уж страшно.
> Это, например, страшно при пакетной сборке, когда пакет, являющийся псевдо-зависимостью,
> удаляется во время сборки искомого. Всё-таки потребности разработчика и мэйнтейнера пакетов
> сильно различны, хорошая система сборки как раз та, которая пытается быть
> удобной в обоих случаях.Кстати, как раз из-за "нечестного" сканера зависимостей очень хочется как раз попинать CMake, а ещё более того - automoc...
при чём тут «пакеты» и откуда это вообще взялось в обсуждении?хинт: у слова «зависимость» много значений. в данном случае речь идёт про аналог 'make depend'. никакие «пакеты» тут не при чём.
а уж cmake вообще мимо кассы. полностью.
пожалуйста, разберись сначала с тем, что такое jam. потому как ты сейчас ворвался с шашкой наголо громить проблемы, которые вообще не относятся к обсуждению.
> при чём тут «пакеты» и откуда это вообще взялось в обсуждении?Очень даже причём. Подразумевалась массовая сборка пакетов, которые используют в этом увлекательном процессе самые разные системы сборки. Это не когда ручками заходишь и делаешь "./configure && make && make install". И даже не когда просишь emerge firefox. Это когда собираешь дистр ОС, например. То есть, повторюсь, задача сильно отличная от той, которую решает обычный разработчик на своём месте - но решаемая при использовании тех же самых систем сборки.
> хинт: у слова «зависимость» много значений. в данном случае речь идёт про
> аналог 'make depend'. никакие «пакеты» тут не при чём.Да, я это прекрасно понял. Ответный hint: зависимости при автоматическом их выстраивании делаются не только по отношению к файлам самого проекта, и даже -MMD не панацея.
> а уж cmake вообще мимо кассы. полностью.
> пожалуйста, разберись сначала с тем, что такое jam. потому как ты сейчас
> ворвался с шашкой наголо громить проблемы, которые вообще не относятся к
> обсуждению.Громить проблемы? Эх, если бы их было так легко разгромить...
Объясняю: массовая одновременная сборка пакетов чревата разными интересными ситуациями. Если собирается пакет посредством системы сборки, которая использует альтернативный способ определения зависимостей между файлами, то у нас возможны, например, следующие ситуации:
1) Заголовочный файл находит компилятор, но не находит система сборки. Результат - пропущенная зависимость. Не особо смертельно, но пережить можно, зачастую - указав зависимость принудительно.
2а) Система сборки игнорирует заголовочные файлы вне каталога сборки. Топорно, нельзя использовать, если надо что-то вроде automoc, накладывает ограничения по использованию симлинков. Кажется, такой режим есть у WAF и/или SCons, но проверять - см. ник. :)
2б) Заголовочный файл не используется компилятором, но его находит система сборки. А вот это уже конкретное западло. Потому что если заголовочный файл найден за пределами системы сборки (правила поиска путей никто не отменял), и в процессе сборки исчезает (пакет, его содержащий, удалён), то сборка рискует обломаться. Именно это происходит в случае с CMake или automoc (звучит особенно забавно в свете, что в последних версиях CMake появилась встроенная реализация automoc). И так же будет вести себя любая другая систем с "нечестным" сканированием зависимостей. А ситуация с исчезновением параллельного пакета в ходе сборки - обычное дело при массовой сборке пакетов.
Именно об этом и был мой комментарий.
> Очень даже причём. Подразумевалась массовая сборка пакетов, которые используют в этом увлекательном"которая использует", конечно же. Прошу прощения за эту и другие возможные описки, сильно спать хочется.
>> при чём тут «пакеты» и откуда это вообще взялось в обсуждении?
> Очень даже причём. Подразумевалась массовая сборка пакетов, которые используют в этом увлекательном
> процессе самые разные системы сборки.возможно, это подразумевалось *тобой*. остальные в этой ветке говорили совсем о другом.
> Да, я это прекрасно понял. Ответный hint: зависимости при автоматическом их выстраивании
> делаются не только по отношению к файлам самого проекта, и даже
> -MMD не панацея.в *данной* дискуссии это вообще не обсуждалось.
> Именно об этом и был мой комментарий.
и совершенно «не в кассу», как я и писал выше. описаные тобой проблемы тоже важные и тоже существуют, вот только в этой ветке их не обсуждали вовсе. мы тут обсуждали — сюрприз! — системы сборки с точки зрения разработчика софта, а не с точки зрения сборщиков пакетов.
ещё намекаю: лично мне проблемы маинтайнеров вообще побоку. если у них там какая-то запара потому, что они не могут в jam — меня это не волнует совершенно. я зато в jam могу, он мне нравится, он мне удобен. потому что сборщик сношается со сборкой пакета гораздо реже, нежели я со сборкой проекта в процессе разработки. поэтому для меня приоритеты сборщиков где-то далеко внизу.
p.s. главное — boost-jam не бери. это ужас, летящий на крыльях ночи. у бустовцев серьёзное ООП гойловного моска: они пихают недоООП даже туда, где это нафиг не надо.а вот всякие патчи к перфорсовскому оригиналу посмотреть стоит.
Пример qbs файла для простого проекта http://qt-project.org/wiki/Qbs-ExampleКраткое введение в qbs https://blog.qt.digia.com/blog/2012/02/15/introducing-qbs/
Справка http://qt-project.org/wiki/Qbs-Quick-Reference
Инструкция по сборке http://qt-project.org/wiki/qbs
>> Пример qbs файла для простого проекта http://qt-project.org/wiki/Qbs-ExampleYAML уже не в моде ?
Ну видать решили не парится и взяли основу языка от QML. Зачем там другие языки? Да и в qbs называют, что отдельный язык для qmake был его фатальным недостатком.
YAML плохой. JSON лучше, поэтому он используется в qbs.
Введение устарело....
Вопрос: про Qt что оно "требовать скрипт configure и небезызвестный syncqt", это относится к сборки самого Qt как такового?А свои программы собирай-конпеляй при помощи QBS? И ничего более?
Ага. Именно так.
Там писали, что если сейчас использовать qbs для сборки Qt, то без configure & syncqt не обойтись. А авторы qbs этого не хотят, и они планируют расширить функционал qbs, чтобы можно было обойтись без других инструментов.
Очень удобная система, конфигурационные скрипты писать и поддерживать одно удовольствие. Собирает шустрее других систем.
Свои проекты внутренние перевел на нее, из QtC пока не собираю еще (использую qmake), но когда нужно сделать полную сборку всех проектов для деплоя, использую qbs.Так же написал для него скрипты сборки старых дельфевых проектов. Что очень экономит время на запуск ide =)
> старых дельфевых проектов.Necromancy is a forbidden art.
я уже боюсь представить что вы скажете, узнав про проекты на фортране =)
наследие примерно четверть века тянется, не все вот так сразу можно переписать на плюсах и qt.
> я уже боюсь представить что вы скажете, узнав про проекты на фортране =)"Вы неплохо сохранились" :)
> наследие примерно четверть века тянется, не все вот так сразу можно переписать
> на плюсах и qt.Наследие некроманов - куда ни шло, а вот разучивать дельфей в 2013 году - вот это странное начинание, да.
> а вот разучивать дельфей в 2013 году — вот это странное начинание, да.с чего бы? язык весьма неплохой.
> Necromancy is a forbidden art.Какая некромантия -2012 год это некромантия ? Видел на диске к хакеру за 12 год , версия для студентов шла за 35 уе ,начальная базовая 90-120 уе ,ентерпрайз 1200 -5000 уе , так что не погоже что труп . Хотя от старого делфи там очень мало -портировали все что могли на платформу NET (во внутренястях не разберался -просто просмотрел и удалил ,Qt и кросплатформенного движка уже нет :-( )
.
> Какая некромантия -2012 год это некромантия ?Какая, какая.... дельфи нынче пользуются только убежденные некроманы. Остальные это давно выбросили. Хуже дельфистов быдлoкодят только одинэсники, и то не факт.
> Видел на диске к хакеру за 12 год ,
Там еще и не такому научат.
> версия для студентов шла за 35 уе ,начальная базовая 90-120 уе ,ентерпрайз 1200 -5000 уе ,
И что? Легионов желающих этим пользоваться нынче чего-то не заметно. Дельфисты в массе своей вымирают, что к лучшему.
> так что не погоже что труп .
Трупозность софта определяется отнюдь не тем кто и сколько за разные версии просит.
> Хотя от старого делфи там очень мало -портировали все что могли на платформу
> NET (во внутренястях не разберался -просто просмотрел и удалил ,
> Qt и кросплатформенного движка уже нет :-( )А он там был когда-то? А так что куть, что дотнет - потомки и наследники си-подобных языков, по поводу чего паскaлеобразному дельфи оно не друг и не товарищ. Ни то ни другое. Как-то конечно на проволоку и скотч можно к паскалю и это прикрутить. Но получится весьма предсказуемый результат.
> .
> А он там был когда-то? А так что куть, что дотнет -Да когдато QT был в делфи 7 -работал через кросc платформенный библиотеку CLX , был даже делфи портирован под линукс (Kulix 3 ),1 и 2 версия работала через wine .
//Насколько я знаю библиотеку CLX перенесли на Лазариус ,и этой библиотеке пофиг что там за графические либы (win32 ,QT (2-3-4) ,GTK ,FTL ) ,приложение скомпилируется с любой из библиотек ,жаль что CLX забросили .
это ж надо уметь и так неграмотно писать, и так задорно смешивать факты с фантазией… даже немного завидую.
А он и не наврал - раньше "дельфи для линукс" именно что базировался поверх Qt, просто совместимость между ОС. Сейчас, в свете LGPLного Qt это никому не нужно, и CLX в том числе.
> А он и не навралещё как наврал. QuickTime там вообще не при чём. это раз. никто никуда CLX не «портировал», потому что оно проприетарное и заточено на конкретную сборку Qt. это два. не работал Kylix «через wine», только ide кое-как пыталась вайнлиб использовать (хреново, да). это три. я не знаю, что такое «FTL», но всё равно фрипаскалевсий аналог VCL *это* не поддерживал. четыре.
всё, хватит.
>никто никуда CLX не «портировал»Проект лазариус портировал библиотеку еще в 2005-2006 годах ,но в стандартную комплитацию не входил из-за лецензионных проблем (вроде фирма борланд не возрожала на перенос но из-за чего то передумала ) ,не потдерживается сейчас в актуальном состояние .Вдобавок сама фирма разработчик портировала CLX под макось .FTL извеняюсь не допечатал правильно FPTL или FPGUI (что с названиями не знаю в доках разночтение )- графический движок ,на стадии сырой альфы ,типа будет родной.
ты извини за наезд, просто очень пост провоцирующий. я-то понял, что ты сказать хотел.
чем это лучше jam и зачем было изобретать очередной велосипед?
Если я захочу перевести свои наработки на это, мне все cmake-скрипты на qml переписывать что ли?
если ты захочешь перенести на любую другую систему сборки, тебе переписывать придется. если эти велосипеды понадобятся, конечно.
для cmake есть ninja
Переходите на .Net framework и Windows 8.