The OpenNET Project / Index page

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

Выпуск сборочного инструментария Qbs 1.16

02.05.2020 11:13

Представлен выпуск сборочного инструментария Qbs 1.16. Это третий выпуск после ухода компании Qt Company от разработки проекта, подготовленный силами сообщества, заинтересованного в продолжении разработки Qbs. Для сборки Qbs в числе зависимостей требуется Qt, хотя сам Qbs рассчитан на организацию сборки любых проектов. Qbs использует упрощённый вариант языка QML для определения сценариев сборки проекта, что позволяет определять достаточно гибкие правила сборки, в которых могут подключаться внешние модули, использоваться функции на JavaScript и создаваться произвольные правила сборки.

Используемый в Qbs язык сценариев адаптирован для автоматизации генерации и разбора сценариев сборки интегрированными средами разработки. Кроме того, Qbs не генерирует make-файлы, а сам, без посредников, таких как утилита make, контролирует запуск компиляторов и компоновщиков, оптимизируя процесс сборки на основе детального графа всех зависимостей. Наличие изначальных данных о структуре и зависимостях в проекте позволяет эффективно распараллеливать выполнение операций в несколько потоков. Для крупных проектов, состоящих из большого числа файлов и поддиректорий, производительность повторной пересборки с использованием Qbs может опережать make в разы - пересборка выполняется почти мгновенно и не заставляет разработчика тратить время на ожидание.

Напомним, что в 2018 году компанией Qt Company было принято решение о прекращении разработки Qbs. Qbs развивался как замена qmake, но в конечном счёте было решено использовать CMake в качестве основной сборочной системы для Qt в долгосрочной перспективе. Разработка Qbs теперь продолжена в форме независимого проекта, поддерживаемого силами сообщества и заинтересованными разработчиками. Для разработки пока продолжает использоваться инфраструктура Qt Company.

Основные новшества Qbs 1.16:

  • Обеспечено слияние списочных свойств в модулях, связанных взаимными зависимостями, что важно, например, при обработке таких флагов, как cpp.staticLibraries;
  • Добавлено автоматическое определение GCC и IAR для микроконтроллеров Renesas;
  • Добавлена поддержка Xcode 11.4 в macOS;
  • Расширены возможности модуля поддержки clang-cl;
  • Обеспечено автоматическое определение MSVC, clang-cl и MinGW в профилях, где явно не определено местоположение инструментария;
  • Упрощено включение и настройка отдельно устанавливаемой отладочной информации (cpp.separateDebugInformation) через секции Application и DynamicLibrary в параметрах проекта;
  • Добавлена поддержка Qt 5.14 для Android и обновлена утилита qbs-setup-android;
  • В настройки Qt.core.generateMetaTypesFile и Qt.core.metaTypesInstallDir добавлена поддержка JSON-файлов, генерируемых утилитой moc (Qt >= 5.15);
  • Добавлена поддержка представленного в Qt 5.15 нового механизма декларирования типов для QML;
  • Добавлена настройка ConanfileProbe для упрощения интеграции Qbs с пакетным менеджером Conan (для C/C++).


  1. Главная ссылка к новости (https://www.qt.io/blog/qbs-1.1...)
  2. OpenNews: Сотрудник Red Hat представил сборочную систему Goals. Выпуск GNU Make 4.3
  3. OpenNews: Google развивает модульную сборочную систему Soong для Android
  4. OpenNews: Выпуск сборочной системы Meson 0.52
  5. OpenNews: Проект Qt прекращает разработку сборочной системы Qbs в пользу CMake
  6. OpenNews: Выпуск сборочного инструментария Qbs 1.15 и среды разработки Qt Design Studio 1.4
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/52863-qbs
Ключевые слова: qbs, qt, build
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (35) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 11:16, 02/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Оно еще выходит? Неплохо.
    Хорошая замена всему этому синтаксическому недоразумению в других сборочных тулзах.
     
     
  • 2.2, Fracta1L (ok), 11:30, 02/05/2020 Скрыто ботом-модератором     [к модератору]
  • –15 +/
     
     
  • 3.3, Аноним (3), 11:46, 02/05/2020 Скрыто ботом-модератором     [к модератору]
  • +3 +/
     
     
  • 4.4, антифрактал (?), 11:49, 02/05/2020 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 4.11, Аноним (11), 18:22, 02/05/2020 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 5.14, Аноним (3), 18:39, 02/05/2020 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 6.16, Аноним (11), 19:50, 02/05/2020 Скрыто ботом-модератором     [к модератору]
  • –1 +/
     
     
  • 7.19, Аноним (3), 20:55, 02/05/2020 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 2.5, Аноним (5), 13:36, 02/05/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А чем тебе месон не угодил? Хотя и как альтернатива цмаке так себе.
     
     
  • 3.6, curver (ok), 15:08, 02/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    gn же есть.
     
     
  • 4.32, Аноним (32), 10:07, 04/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Чем лучше месона? Ссылка есть, а то не нагуглить это
     
  • 3.8, Ivan_83 (ok), 18:00, 02/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А в чем минусы месона?
    (спрашиваю потому что cmake кажется каким то тяжёлым по зависимостям)
     
     
  • 4.15, Аноним (11), 18:42, 02/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вообще-то у CMake только одна тяжелая зависимость - это сам CMake.

    Хоть я до Kotlin не особо любил Java, и наоборот любил C/C++, но после этой насмешки над всеми C-подобными языками под именем CMake (ибо неясно, что делает буква C в его названии)...

    ...после всего этого Java-шный Gradle на стероидах Kotlin DSL, со всеми архитектурными изъянами Gradle и со всеми его зависимостями воспринимается гораздо приятнее, чем это издевательство над C/C++ под названием CMake.

    На Gradle внезапно прекрасно собираются проекты на разных языках, включая C/C++.

    Увы, видимо сделать архитектурно красивую систему сборки невозможно в принципе из-за неясности вопроса - а что же такое сборка в общем случае? В частном же случае всегда можно написать просто сборочные скрипты на чем угодно - и будет вам сборка!

     
     
  • 5.23, anonimm (?), 09:19, 03/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    В CMake C=Crossplatform, а не C/C++. Не знаю, чем Вам не угодил CMake, но тащить Java в C/C++-разработку выглядит ещё бОльшим издевательством.
     
     
  • 6.33, Аноним (32), 10:08, 04/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    cmake неугоден:
    -  синтаксисом,
    -  набором инструментария (FindLibrary)
    -  сложностью написания и анализа сборочны сценариев
     
  • 6.35, Аноним (11), 14:40, 04/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Издевательство над чем?
    Над сферичным конем в вакууме?

    Вот создатели CMake нагло поиздевались над языками программирования, ради сборки проектов на которых, какбы все это создавалось.

    А над чем у вас будет издеваться Java? особенно в переводе на Kotlin, если можно сделать так, что вся JVM и останется только в среде разработке, а в продакшн уйдут чистые бинари (или теперь даже байт-код на другие VM, отличные от JVM, если не устраивает).

    Даже при всех недостатках Java, которые можно себе нафантазировать (а обычно это именно фантазии и байки, см. ниже) - сборка на Gradle, даже при всех недостатках и его тоже - по-любому получается "меньшим из зол" по сравнению с CMake.

    Это я говорю, как начинавший с C/C++, и долго его изучавший, кому тоже не нравилась когда-то Java по сравнению с C++, говорю:
    - времена изменились!
    - Java сильно исправилась (и по времени эти исправления "случайно" совпали с выходом новых стандартов 11+ самого C++).

    Да, у Java был долгий путь развития, однако это уже прошлое.

    А если вам нужна простая классическая сборка без автоанализа и автозагрузки зависимостей с авто-тестированием и стиркой белья разработчикам (ну если заказчик или спонсор требует, для создания рабочих мест его менеджерам, которым иначе нечем будет больше заняться после внедрения)
    ... если этого всего не нужно
    - просто напишите сборочный скрипт, и не нужен ни CMake, ни Gradle...

    ... только сейчас все больше в моде всякие CI/CD, и уже никуда не денешься от сложных сборочных уже даже фреймворков с интегрированным Agile-планированием и чатом с поддержкой визуализированных тикетов для Scrum-мастера, не умеющего читать код...

    ...в-общем от качества DSL для разработчиков сейчас все зависит гораздо больше, чем от нескольких лишних зависимостей в сборочном окружении... а если сборочное окружение удается вообще выпилить из продакшена... скоро видимо везде будут одни сплошные сборочные окружения... ну и возитесь там сами с этим CMake!

     
  • 5.29, Ivan_83 (ok), 01:22, 04/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Там ещё libuv и ещё штук 5+ портов ставится на фре.
    Но да, сам цмейк собирается дольше остальных. Заметно дольше.

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

    В общем я пока смотрю на месон и пытаюсь понять: стоит ли на него сваливать с цмейка в своих перснальных проектах.
    Как вариант я могу иметь обе системы, но хотелось бы понять перспективы.

     
  • 4.18, Аноним (18), 20:06, 02/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Минус в том, что это — боль для сборщика и потребность учить питон для кодера. (Вот только не надо про то, что питон знают все, и уж тем более про то, что там нечего учить.)
     
     
  • 5.25, Аноним (11), 09:43, 03/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Поэтому лучше уж выучить Kotlin, чем Python. Или хотя бы Kotlin DSL. Там, в отличие от Питона, есть полноценная система статических типов с выводов.

    Поскольку сборка в основнов и используется для статически типизированных языков.

    А в динамических скриптовых языках чего там собирать? Если все и так в рантайме.

    И в отличие от Qbs, Kotlin - это все-таки язык общего назначения, и даже Kotlin DSL используется в разных системах, а не только в одной системе сборки. Как и Python, зато еще и со статически компилируемыми типами.

    В Kotlin поддержка функционального программирования, в Python ФП практически никакое, одни только лямбды, как объекты первого класса - это еще не ФП. А вот неизменяемые переменные, хвостовая рекурсия... это уже...

    Кстати, в И-нете есть много синтаксических сопоставлений Kotlin и Python. Именно синтаксических, если кто захочет докопаться, семантика у них разная. Однако это про то, как легко перейти с Python на Kotlin. Да, вместо отступов - старые добрые Сишные фигурные скобочки, зато не нужно ставить ";" в конце строк. И скобки во многих случая можно не использовать - код получается не менее компактным, чем в Python, а за счет более развитого синтаксиса - еще и более компактным.

    О да! Будете иметь дело с JVM! Однако, по сравнению с CMake, который типа на чистом C (или C++? - неважно), однако извратили так, что уж лучше пусть будет JVM.

    ...а чем это мы? А! ...и вот представьте все это есть у вас в системе сборки!

     
     
  • 6.30, Ivan_83 (ok), 01:25, 04/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Мне не типы нужны, мне проекты собирать :)
    Развитый синтаксис - много времени на изучение, вон кресты себя активно хоронят: скоро старые спецы помрут а новые не пидут, потому что учится 3-5 лет чтобы получать столько же сколько те кто учился языкам по проще за пол года смысла нет.
     
     
  • 7.34, Аноним (11), 13:56, 04/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Вам не нужны типы - тогда Питон для вас самое то. Никто не спорит.

    А есть такие люди, которым нужны типы, И, одновременно им нужно собирать проекты.

    А также если этим людям не проблема изучать статически-типизированные языки - то для них системы сборки с типами, встроенными прямо в сборочный DSL - тоже самое то.

    Каждому свое. По способностям и по возможностям к освоению.

    C++ ни разу не хоронят, особенно после стандартов 11+, он живее всех живых. Просто он придерживается классической схемы, когда компилятор отдельно, а тулсеты, включая пакетные менеджеры - отдельно. И не встроены в язык, как объекты первого класса, потому что фишка C++ - это филигранное управление памятью с одновременным высоким уровнем абстрактных типов данных.

    Да, у C++ появилось много достойных конкурентов, даже Java подтянули, до уровня "нескучности", хоть и оставив многословность, ну, это как раз и исправляет Kotlin.

    А тут еще даже Haskell активно пробивается в "промышленность" из "академичности"...

    А еще потребности Data Science...

    Так что людям, _способным_ осваивать абстрактные типы данных, и делать _сборки_ сразу не понижая уровни абстракций
    - есть где развернуться!

     
  • 5.28, Ivan_83 (ok), 01:15, 04/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну это можно писать тому кто не видел месона и ничего с ним не делал.

    Как сборщик - я как раз вижу что месон требует меньше зависимостей прежде чем он станет рабочим в системе.
    Как программист - учить Cmake с его самобытным синтаксисом или месон с питоноподобным - последнее кажется более перспективным.
    Хотя я лично очень плохо воспринимаю ихние пробелы и pep8 (к месону пока не относится).

    Но мне приходится колупатся в опенсорсных проектах и с месоном и цмейком, при этом на месоне почему то мне или вообще не приходится ничего делать (наверное пока не так распространёт) или там сразу всё очень компактно и понятно (опять же может мне просто везло).
    На цмейк это часто какие то простыни откровенного говнокода.

    Не знаю, может быть все сборочные системы обречены скатыватся в УГ и становится на вид как автотулс, и цмейк просто старше и ближе а месон ещё только в начале пути.


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

     

  • 1.7, Аноним (7), 16:28, 02/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    qbs, qmake... и чего только не придумают эти культяшники...
     
     
  • 2.9, ABBAPOH (ok), 18:03, 02/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    qmake надо закопать и никогда не откапывать, слышите, НИКОГДА
     
     
  • 3.12, Аноним (11), 18:25, 02/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вылезает потом такой мертвец из могилы и говорит: "Ха ха ха! А я - qmake!"
     
     
  • 4.21, Элитный линуксоид (?), 08:35, 03/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Как смешно(нет).
     
     
  • 5.22, Аноним (11), 09:12, 03/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Чем примитивнее юмор, тем древнее тенденция... Ибо сказано в Писании...ЫЫЫЫ!... Чем глубже закопать, тем страшнее потом вылезет!
     

  • 1.10, Аноним (10), 18:15, 02/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Qbs - не поддерживают.
    А почему он всегда самой последней вресией присутствует в Qt Creator ?
     
     
  • 2.13, ABBAPOH (ok), 18:28, 02/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что сделать апдейт ревизии сабмодуля ничего не стоит=)

    На самом деле, бывший мейнтейнер Qbs продолжает пилить интеграцию в креаторе

     

  • 1.17, Аноним (17), 19:58, 02/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Самая удобная система сборки для c++. Стоит того, чтобы отвязать ее от Qt.
     
     
  • 2.20, ABBAPOH (ok), 22:08, 02/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Но зачем? Чем мешает зависимость от Qt? Ну приедет 2-3 библиотеки (QtCore/QtScript/QtGui), сильно страшно что ли?

    Надо добавлять поддержку других языков и библиотек (boost, poco) из коробки - это да. Собственно, я работаю над этим=)

     
     
  • 3.24, anonimm (?), 09:22, 03/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если Вам нужно собрать Ваш проект на сервере, на котором у Вас есть учетка, но нет прав установить Qt, а админ не хочет "загаживать сервер всяким гуёвым хламом" (да, бывают и такие)?
     
     
  • 4.26, Аноним (26), 10:42, 03/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А можно ещё вприсядку это самое. А админ, который не хочет делать свою работу, заменяется другим.
     
  • 4.27, ABBAPOH (ok), 14:12, 03/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Поставьте  Qbs в хомяк вместе с библиотеками, делов-то. Требование "использовать системную Qt" достаточно странное, не все диcтрибы имеют свежую Qt.
     
  • 2.31, Аноним (31), 09:34, 04/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Как ты её отвязывать собирался? С собой половину Qt таскать?
     

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



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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