Доступен (http://blog.qt.digia.com/blog/2013/11/06/qbs-1-1-0-released/) новый выпуск развиваемого проектом Qt сборочного инструментария qbs (http://qt-project.org/wiki/qbs) (Qt Build Suite). Qbs использует упрощённый вариант языка QML для определения сценариев сборки проекта, что позволяет определять достаточно гибкие правила сборки, в которых могут подключаться внешние модули, использоваться функции на JavaScript и создаваться произвольные правила сборки. В отличие от qmake, qbs не привязан к Qt и изначально рассчитан на организацию сборки любых проектов.
Используемый в qbs язык сценариев адаптирован для автоматизации генерации и разбора сценариев сборки интегрированными средами разработки. Кроме того, qbs не генерирует make-файлы, а сам без посредников, таких как утилита make, контролирует запуск компиляторов и компоновщиков, оптимизируя процесс сборки на основе детального графа всех зависимостей. Наличие изначальных данных о структуре и зависимостях в проекте позволяет эффективно распараллеливать выполнение операций в несколько потоков. Для крупных проектов, состоящих из большого числа файлов и поддиректорий, производительность повторной пересборки с использованием qbs может опережать make в разы - пересборка выполняется почти мгновенно и не заставляет разработчика тратить время на ожидание.
В новой версии:
- Поддержка вложенных проектов и возможность встраивания одного проекта в другой;
- Существенно расширены средства отслеживания изменений. Учтены дополнительные факторы, которые могут потребовать пересборки частей проекта или, наоборот, сигнализируют об отсутствии необходимости пересборки.
- Улучшены средства диагностики ошибок, таких как синтаксические ошибки в файлах проекта и отсутствие необходимых сведений в профиле. Увеличена информативность сообщений об ошибках;
- API расширен для предоставления большей информации в интегрированную среду разработки, что позволило улучшить поддержку qbs-проектов в грядущем выпуске Qt Creator 3.0;
- Добавлена большая порция новой документации, устранены белые пятна в описании языка определения параметров проекта.
- В состав включён графический интерфейс для редактирования профиля проекта и изменения настроек.URL: http://blog.qt.digia.com/blog/2013/11/06/qbs-1-1-0-released/
Новость: http://www.opennet.me/opennews/art.shtml?num=38361
Я рад! Потому что autotools - засохшее мамонта, cmake - тоже отвратен, хотя признаю что cmake штука мощная. Но всё же, планирую сесть на QBS.
Но всё же планирую подсесть на QBS.
/fixed
Можешь не благодарить :-)
А я не рад.
До scons'а это не дотягивает. Лучше бы улучшили поддержку qt-шностей в сконсе, ей-богу.
> А я не рад.
> До scons'а это не дотягивает. Лучше бы улучшили поддержку qt-шностей в сконсе,
> ей-богу.https://wiki.debian.org/UpstreamGuide
Please don't use SCons. It is hard to use it correctly. For instance SCons is designed to ignore environment variables such as CFLAGS (unless your add code for this). It also does not support DESTDIR out of the box. As an upstream you have to explicitly add code for that (or Debian has to patch). Support for SONAMEs (library versioning) is also absent. The general observation is that many projects, that use SCons, do not have a working install target. Since projects work around these limitations individually there is no way to just use a SCons project in Debian, but more work is required to invoke it correctly.
The gentoo wiki has a detailed list of shortcomings.
If you choose to use SCons anyway, please ensure that the usual environment compiler variables (CC, CFLAGS, ...) and path variables (DESTDIR, BINDIR, LIBDIR, ...) are honoured. There is a recipe, that addresses some of these.
Уфф. Вот какая штука. Мантейнерам большого репозитория, без сомнений, удобно, когда сборочная среда единообразно вписывается в их окружение. А насколько корректно при этом работает сама сборочная среда, их уже не волнует: главное, чтобы корректно собирался конечный результат.А вот если вы разработчик, ситуация обратная: вы можете быть совершенно равнодушны к тому, как ваша среда реагирует на стандартные переменные окружения, но будете огорчены, если зависимости в проекте отслеживаются не вполне. Вот с последним, как раз, сконс справляется лучше всех.
И да, в моих SConscript, переменные окружения поддерживаются, это вообще не проблема.
Кстати, не я н понял пассаж насчёт DESTDIR. Корректная(!) сборка проекта в отдельный buildir, это вообще исконная фишка сконса.
Порог вхождения в сконс (в случае не очень простых проектов) высоковат, это да. И забывается быстро. С нуля, сложный SConscript/SConstruct я сейчас сходу, "с чистого листа и без бумажки" не напишу, пожалуй. Не волнует: есть наработанный шаблон.
Видел я пару проектов на этом вашем сконсе. Количество костылей не оправдывает гибкости. Практически во всех случаях можно было просто доосилить cmake.
можно подробнее насчёт костылей?PS: про cmake, лучше не надо. Теряет зависимости, требует перезапуска после изменения состава исходников.
> можно подробнее насчёт костылей?Вон там выше написано достаточно для того чтобы не пользовться этим гомном. Если оно кладет на переменные окружения - должно помереть лютой смертью.
> Практически во всех случаях можно было просто доосилить cmake....который тоже кривая и глючная хрень, так что можно было не выделываться и доосилить автокрап. Хоть он и крап, но с точки зрения майнтайнеров и прочая - наилучший вариант. Т.к. за годы этот крап допинали до состояния когда он запускается на любой кофемолке с шелл-интерпретатором и как правило может более-менее внятно послать, человекочитаемым текстом, если где-то чего-то для полного счастья не хватило. И в случае чего - логи нормальные есть. А в cmake забодаешься вкуривать почему оно отвалилось. Более того - в половине случаев прожЕкты которые дро^W на cmake - умудряются генерить make file который потом ... обломается где-то на середине сборки. Автокрап в этом плане просто на голову лучше - там как-то обычно осиливают прикрутить проверку всех нужных проекту либ без десяти итераций запрыгов по граблям.
http://postimg.org/image/8uw5xoj8h/
Зачет за автотулз, у вас отдельный штат кодеров пишет билд скрипты?;)
> отдельный штат кодеров пишет билд скрипты?А вы специалист по циклу for?
> Я рад! Потому что autotools - засохшее мамонта, cmake - тоже отвратен,
> хотя признаю что cmake штука мощная. Но всё же, планирую сесть на QBS.Ну да, с твоим ником как-то так и надо, страдать легким программизмом в своей вьюжлстудии. При этом пальцем у виска будут крутить и *никсоиды, и вeндyзятники.
Использую уже год, отличная система, собирает шустро и удобно. Очень хорошо поддерживать кучу разных аппаратных платформ и кастомных компиляторов.
(libc-linux-x86, x86_64, armlinux-elf, arm-uclinux, mingw).
Использование что qmake, что netbeans-овых конфигов было болью.Кроме того прикрутил сборку паскальных проектов через него же. все удобно.
> Использую уже год,Главное не время, а количество проектов и поддерживаемых платформ.
Платформы - написал. Количество проектов - 3 - в каждом около десятка подпроектов (статические и динамические либы и приложения).Кто-то скажет - мало, а по мне так вполне боевое крещение. QBS мал и юн, но уже может конкурировать по некоторым показателям (для меня критично - удобство конфигов и их поддержка).
т.е. компилятор - 1.
Что не нравится - Запуск внешних програм опять через одно место.
Если мне нужно простейшее - собрать, если удачено загрузить на сайт по фтп, если не удачно - послать письмо и откатить на прошлую версию из гита. В make файле это три строки, тут надо импортировать модули, и на javascript писать портянку с калбеками.
> собрать, если удачено загрузить на сайт по фтп, если не удачно - послать письмо и откатить на прошлую версию из гитаСистема сборки должна собирать, а не кофе варить и тапочки приносить. Пускай лучше делает одну вещь, но хорошо.
> В make файле это три строки
Дык и напиши себе мейкфайл из трёх строк. Для самой сборки он будет вызывать qbs. В чём бида-то?
> Система сборки должна собирать, а не кофе варить и тапочки приносить. Пускай
> лучше делает одну вещь, но хорошо.Как бы было неплохо если оно не только собрать программу может но и оформить это в нечто готовое. А вот тут уже может понадобиться вызов внешних программ.
Уже научился собирать в директориях отличных от buid?
И на багтрекере слили, и тут сливают.https://bugreports.qt-project.org/browse/QBS-116
>> гибкие правила сборки
на то они и гибкие
с абсолютными путями у меня работает норм. Для цели "положить бинари в ../bin после сборки" есть команда install.
Тьху, и тут JavaScript...
Попробовал, до cmake даже близко не дотягивает. Какой-то передутый qmake с жабоскриптом, сохранивший все генетические проблемы.
хотелось бы конкретики
> Какой-то передутый qmake с жабоскриптомтак как в этой теме есть специалисты -- то заодно и спрошу..:
подскажите пожалуйста -- как на qmake воссоздать аналог следующей qbs-декларации:
cpp.warningLevel: "all"
cpp.treatWarningsAsErrors: true???
(разумеется для случая разных C++компиляторов, а не только для GCC)
> подскажите пожалуйста -- как на qmake воссоздать аналог следующей qbs-декларации:
>
> cpp.warningLevel: "all"
> cpp.treatWarningsAsErrors: true
>
> ???
> (разумеется для случая разных C++компиляторов, а не только для GCC)Не надо это прибивать гвоздями. Есть же CFLAGS, CXXFLAGS.
Но если очень хочется, есть http://stackoverflow.com/a/19661046/933161
>> Какой-то передутый qmake с жабоскриптом
> так как в этой теме есть специалисты -- то заодно и спрошу..:
> подскажите пожалуйста -- как на qmake воссоздать аналог следующей qbs-декларации:
>
> cpp.warningLevel: "all"
> cpp.treatWarningsAsErrors: true
>
> ???
> (разумеется для случая разных C++компиляторов, а не только для GCC)вангую: в новой версии ку-бе-эс меняется синтаксис, и весь мифический выигрыш от якобы более удобного задания известных опций превращается в красную сеточку немного влажных глаз обиженного лица разработчика невнятно мямлящего "сейчас.. тут надо кое-что подправить... да ерунда в принципе" во время судорожного гугления.
Чем это лучше cmake?
Я бы спросил, чем одна фигня отличается от другой? Скачиваешь программу, которая распространяется лишь через исходники, а там нужен cmake, ...или qmake, ...или ещё какой-нить. К чему переходить на странные штуки из зоопарка, когда есть make?
> Я бы спросил, чем одна фигня отличается от другой? Скачиваешь программу, которая
> распространяется лишь через исходники, а там нужен cmake, ...или qmake,
> ...или ещё какой-нить. К чему переходить на странные штуки из зоопарка,
> когда есть make?если хватает мозга выкачать исходники, то хватит мозга и qbs,cmake,etc выкачать. gcc и make уже по умолчанию во всех дистрибутивах поставляются при установке голой системы?
> Скачиваешь программу, которая распространяется лишь через исходники, а там нужен cmake, ...или qmake, ...или ещё какой-нить.
> К чему переходить на странные штуки из зоопарка, когда есть make?А что, make значит не нужен? А то что компилятор нужен, не смущает?
А вообще, make что-то сложнее hello world не соберёт, ибо не умеет искать зависимости и абстрагироваться от особенностей систем. Даже для hello world нормальный Makefile написать - для некоторых непосильная задача. cmake же всё делает для разработчика, и, на секунду, умеет генерить не только makefile но и проекты для ide.
>А вообще, make что-то сложнее hello world не соберёт...Зае**сь, hello world на 72 метра в архиве. kernel.org , если чо.
Ну посмотрите ради интереса объём кода их makefile'ов, откуда они получаются и сколько там есть дополнительных утилит. И да, ядро - проект без зависимостей, в этом смысле любоя вшивая пркладуха намного его сложнее.
>>А вообще, make что-то сложнее hello world не соберёт...
> Зае**сь, hello world на 72 метра в архиве. kernel.org , если чо.kernel is special. Это проект в себе. Без внешних зависимостей.
>>>А вообще, make что-то сложнее hello world не соберёт...
>> Зае**сь, hello world на 72 метра в архиве. kernel.org , если чо.
> kernel is special. Это проект в себе. Без внешних зависимостей.андроид.
> андроид.Что - андроид? Кернел собирается без всяких ведроидов.
Андроид и ядро линукс = проекты уровня хелло ворлд?
там проблема в том, что на самом деле билд-система уровня autotools/cmake/whatever переписана на makefiles. Линусу виднее, но лично я не хочу писать к своим проектам еще и свою билд-систему
Проблема в том, что вы не понимаете чем сборка ядра отличается от сборки user-space.Все autotools, cmake и остальные существуют для облегчения создания исполняемых файлов, библиотек (shared и static) и модулей (которые dlopen) с учётом зоопарка стандартов, заголовочных файлов и других библиотек.
Для ядра это просто не нужно. Хотя nvidia могла бы...
> Хотя nvidia могла бы......прикупить вазелин :P.
Это лучше тем, что моднее
И молодёжнее, ага. Жабоскрипт же
Канечно, жабоскрипт это вам не гуиле какой-то.
Лучше бы сделали генерацию ninja, а так ...