Представлен выпуск сборочного инструментария Qbs 2.0. Для сборки Qbs в числе зависимостей требуется Qt, хотя сам Qbs рассчитан на организацию сборки любых проектов. Qbs использует упрощённый вариант языка QML для определения сценариев сборки проекта, что позволяет определять достаточно гибкие правила сборки, в которых могут подключаться внешние модули, использоваться функции на JavaScript и создаваться произвольные правила сборки...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=59032
Дожили. Для сборки билд-тулзы нужен Qt. Скоро ядро Linux без GTK+ не будет собираться.
Для сборки Cmake нужен Qt. Иначе Cmake-GUI не соберется
> Скоро ядро Linux без GTK+ не будет собираться.Ну уже много лет с qt/gtk+ ядро конфигурируется намного легче.
Так как "make menuconfig" не такой удобный как "make gconfig/qconfig"
Попробуй в vi. Тебе понравится
Я лучше в плейере. Там хоть музыка, а не просто писк.
> "make menuconfig" не такой удобный как "make gconfig/qconfig"А у меня всё с точностью до наоборот. Считаю самым удобным как раз menuconfig. Ну и oldconfig при минорных апдейтах.
GTK надо писать именно так "GTK", без знака "+" https://www.opennet.ru/opennews/art.shtml?num=50115
К (счастью|сожалению) многие уже пересели на cmake, так что, увы. А ещё говорят, что и его уже абстрагировали. Но идея была интересная.
Уже дропнули и перешли на meson, на cmake всякая маргинальщина.
Да, meson тоже напоминает Autotls и солянку из Perl^W Python скриптов.
Функционала больше, но вот сама реализация конечно печальная.
Окей, так и запишем: телеграм - маргинальщина.
Именно так.
Чтобы собрать проект для STM32 нужно всего чуть больше 1900 строк кода в CMAKE. Или чуть более 600 в QBS.
А про какие строки разговор? Ты считаеш строки проекта? Или еще и то что поставляется штатно с билдсистемой?Если про юзерские, то как-то сильно много.
А если про все , то всем пофиг что там под капотом.
> А про какие строки разговор? Ты считаеш строки проекта? Или еще и
> то что поставляется штатно с билдсистемой?
> Если про юзерские, то как-то сильно много.
> А если про все , то всем пофиг что там под капотом.Про юзерские. Так как надо указать ручками смещение, опции кросскомпилятора, либы STM32 (HAL) для подключения устройств контроллера и подключенного оборудования и прочие параметры сборки.
Например, чтобы реализовать в проекте компиляцию либ работы microsd с FAT32 на контроллере STM32F103 нужно дописать около кполучтысячи строк кода в проект CMAKE.
Проект CMAKE осцилогрофа на STM32 Discovery более 600 килобайт весит, при том, что сама прошивка 256 КБ. Если это все не прописать, то в каждую либу нужно вносить ручками частоту работы процессора, частоту работы шины и т.д.Да, на форумах есть готовые CMAKE файлы для камушков и либ к ним. Но это не штатный код CMAKE.
Звучит как какой-то безумный онанизм вместо использования штук вроде стм32кубИде хотя бы в плане начальной генерации кодаА если стм-ина жирная, то даже с тактированиями писаниной можно просто задолбаться
STM32Cube помогает настроить ножки самого камня, а не настроить то, что эти ножки будут пинать.
FAT32 можно поддерживать на SD-карте, USB-диске, flash-памяти. Либа одна, а настройки у нее разные, которые не задашь через кубик.> то даже с тактированиями писаниной можно просто задолбаться
Вот поэтому и надо писать ооооооооооооочень много кода CMAKE.
Я не знаком со спецификой, но написать простой Makefile - ещё хуже будет?
Вроде не хуже. Но и не лучше.
QBS-ом проще.
Тут основной профит от Qbs в том, что он передает в IDE всю инфу о собираемом проекте, тулчейнах и т.п.Не забывайте, что в мире MCU есть зоопарк архитектур и тулчейнов.
Например, проект под STM32 можно собрать как минимум 4-мя разными тулчейнами, на любителя: GCC ARM, IAREW ARM, KEIL ARM, COSMIC ARM.
И IDE должна корректно подсветить все инклуды тулчейна, его дефайны и т.п.
Т.е. Qbs все это дает из коробки, ничего самому не надо для этого делать.
Т.е. тут вмешивается извечная проблема борьбы ИДЕ с проектом и CLI.
Я просто не понимаю каким боком IDE нужна ещё какая-то инфа кроме проекта - она либо поддерживает компилятор, либо нет. В том же кодеблоксе один проект можно (было? давно не трогал) собрать разными тулками.
ИМХО, сама ИДЕ не должна ничего знать о том как и что и каким компилятором собирать.Она должна предоставлять некоторое АПИ для плагинов, чтобы детектить компиляторы и АПИ для интеграции с системами сборки.
В этом случае сборкой занимается система сборки, как не банально звучит, а ИДЕ только отображает события и т.п. от системы сборки (через плагины).
Что и сделано, например в QtC, VSCode и может где то еще (не проверял).
А универсальные комбайны - это неэффективно, ИМХО.
Ну, тогда тебе и Kate - IDE. А мне нужен годный дебуггер, дизасёмблер, графопостроитель и ещё 9000 фич, включая какой-нить весёлый UML. )
Не не. Тут речь идет, как я понял, не о генерации с помощью кубика.Вот сгенерили мы целиком сам ХАЛ и некоторую обвязку кубиком.
Теперь надо как то эти файлы подключить к проекту.
Путей два:
1. Или прописывать их и их зависимости ручками.
2. Или взять какое то готовое решение.
Вот для STM32 на гитхабе есть готовое решение на CMake. Где достаточно указать путь к директории с ХАЛ-ом, а уже отдельные компоненты: тип MCU, модули GPIO, таймеры, USB и прочее подключать через готовые штукенции, реализованные в решении, где пользователь даже не знает, какие файлы из ХАЛ подтянулись.
Поменяли тип MCU и автоматом потянулись из ХАЛ все нужное для этого MCU, красота.
То же самое можно сделать и для Qbs, просто нужно чтобы кто то взял на себя ответственность выложить это на гитхаб и поддерживать.
В этом случае на Qbs это будет выглядеть гооораздо прозрачнее, проще, красивее и т.п. чем на CMake.
make при грамотном использовании не оказывает ощутимого влияния на общее время сборки/пересборки проекта
в принципе, для хелловорлдов подойдет и однострочная команда gcc, размещенная в виде коммента в laba1.c. Что касается крупных проектов, то make им не подойдет.
Ядро Linux достаточно крупный проект?
Что то тут https://www.kernel.org/doc/html/v4.10/process/changes.html список необходимого сильно шире чем make и компилятор. Даже перл присутствует.
Так что маке сам по себе это как раз то для хеловордов. Без настоящего ЯП типа перла - унылая поделка.
Насколько я знаю - perl там используется в основном для вспомогательных вещей, типа проверки патчей, работы со списками сопровождающих и тому подобных вещей, не влияющих на сам процесс сборки.
Оказывает, к сожалению. Время пересборки (incremental build) вместе с make в сотни раз медленнее чем с qbs, meson, ninja, да почти что угодно (кроме всратого scons который умудряется делать инкрементные сборки медленнее чем make сделанный 40 лет назад).К слову Qbs не замена make, а скорее замена meson+ninja, cmake+make, SCons, MSBuild autotools+make и вот такого прочего. т.е. не просто сборка, а полный комбайн.
Я не агитирую переходить на Qbs, к сожалению он сильно отстает по фичам от cmake а по интеграции с IDE от вообще чего угодно (кроме qt creator на все остальное забей).
"В сотни раз" -- сильное преувеличение. https://hamelot.io/programming/make-vs-ninja-performance-com.../ И скорость сборки зависит не от инструментария автоматизации сборки, а от компилятора -- он требует больше всего ресурсов (любых, не важно, ЦП, памяти или I/O), поэтому производительность упирается именно в него.
Да, именно так, всё упирается в компилятор, а не в make или что-то ещё.
Для полной пересборки да, все упирается в производительность компилятора.Но при инкрементальной сборке, когда из сотен файлов поменялся один-два, перекомпилироваться должны только эти два файла и после этого запустить линковщики только для измененных либ. Но для того, чтобы понять, какие файлы поменялись и как оптимально пересобрать/перелинковать только нужные изменения, система сборки должна построить дерево зависимостей и перешерстить все эти сотни файлов. А потому она должна быть очень быстрой.
Так что, если просто брать готовый сторонний проект и немодифицируя его собирать, то, в принципе, без разницы, какая у него система сборки. А вот если быть разработчиком этого проекта, то быстрая инкрементальная сборка очень важна.
По-моему, сравнивать даты изменения *.c и *.obj умел ещё make - разве нет?
Почитал остальной ваш тред - можете не отвечать :D
>> Время пересборки (incremental build)
> скорость сборки зависит не от инструментария автоматизации сборки, а от компилятораПо вашей ссылке речь идёт о чистой сборке, а начальное сообщение — про инкрементальную сборку, которая нужна разработчикам десятки и сотни раз в день.
Для make совершенно типично долго обходить все каталоги, чтобы через 10+ секунд скомпилировать и перелинковать один файл. Для больших проектов это просто ад.
Пересборку make делает очень быстро. У меня каждый раз делается замер общего времени компиляции/сборки, времени компиляции каждого модуля, времени линковки и прочего. Причём сценарии сборки make довольно большие (более 1500 строк чистого кода - это уже после вычета комментариев и пустых строк) и используется Perl для вспомогательных целей. Вывод следующий: как для полной сборки проекта, так и для частичной пересборки, ситуация примерно одна и та же, а именно: практически всё время затрачивается на работу компилятора gcc/clang, а всё остальное (make, линковщик...) занимает очень незначительное время, уменьшение которого на общее время как-то существенно повлиять не может.
Время сборки при использовании make практически такое же, как при использовании любого другого инструментария для организации сборки. Всегда замеряю общее время сборки проекта, каждого модуля в отдельности, и всегда оказывается, что практически всё время сборки тратится на работу компилятора gcc/clang (clang обычно чуть быстрее gcc), а не make. Это, конечно, при условии грамотного написания сценариев make. Всё, что вы можете выиграть от перехода на более новые системы сборки - это десятые доли секунды.
> Всё, что вы можете выиграть от перехода на более новые системы сборки - это десятые доли секунды.Всё, что могут выиграть пользователи — это проценты, да. А разработчки могут каждый день экономить по пол часа. Вообще — тут как с git.
Ситуация похожа на то, что Linus говорил про git (https://www.youtube com/watch?v=4XpnKHJAok8&t=3287s).
Разница не просто «быстрее или медленнее».
Если сборка занимает секунду, то в случае сомнений можно нажать build и посмотреть результат.
А с make нужно ждать 10-20-30 секунд, и это всё меняет.
Замеры времени показывают, что практически всё время затрачивается на работу компилятора. Make, линковщик и прочее занимает максимум 5% времени в худшем случае. Если у кого-то иначе, смотрите, что не так с вашими сценариями сборки make, изучите make лучше - у него много опций и возможностей которые надо понимать, чтобы всё хорошо работало. Также надо понимать опции компиляторов gcc/clang, некоторые из которых непосредственно взаимосвязаны с работой make.
> Замеры времени показывают, что практически всё время затрачивается на работу компилятора.Вы понимаете, что значит incremental build?
Давайте напомню: это повторная сборка без очистки сборочной директории. Допустим, в проекте 100 C++ файлов. Разработчики, как правило, редактируют их по одному. И вот в случае, если разработчик что-то делает в одном файле и периодически собирает проект для проверки, то компилируются не 100 файлов, а один. И в этом случае проявляется неэффективность сценариев make в работе с файлами. Большая часть времени в такой сборке уходит не на компиляцию, а на проверку того, что 99 файлов компилировать не надо.
> линковщик и прочее занимает максимум 5% времени в худшем случае
Включите LTCG или отладку и линковка сразу займёт больше времени. Но смысл в том, что в инкрементальных сборках время работы make куда больше 5% и вполне бывает 50% и даже 90%.
Вот делает разработчик, например, тест для какого-нибудь toolkit — Qt или GTK.
Запуск make даже без изменившихся файлов займёт десятки секунд, а потом компиляция+линковка теста ещё 1-3 секунды.
Никто каждый раз не перекомпилирует весь проект. Это обычный режим работы. Все в курсе об этом режиме. Для этого режима и предназначен make и работает он очень быстро. Если в проекте нет изменений, то на среднем проекте проверка всего и вся занимает десятые доли секунды. У меня он работает так. Всё работает быстро, и ничего не тормозит. При этом сценарии make не маленькие - более 1500 строк (это уже за вычетом комментариев и пустых строк).
Выше уже приводили ссылку, где сравнивается производительность make и ninja, которая разрабатывалась как улучшенная и ускоренная альтернатива make: https://hamelot.io/programming/make-vs-ninja-performance-com.../
Это правдивые данные. По факту разница в производительности между ними очень незначительная, как для полной, так и для частичной пересборки проекта, хотя для частичной пересборки она таки есть, но абсолютно некритичная - десятые доли секунды. То есть для тех, у кого уже есть отработанные годами сценарии сборки make, переходить на что-то другое смысла никакого нет.
> (кроме qt creator на все остальное забей).Есть же еще плагин для VSCode. ))
когда уже сборочная система на расте?
> когда уже сборочная система на расте?давно уже есть: https://www.opennet.ru/opennews/art.shtml?num=58933
основная проблема qbs была в отсутствии документации, qbs-файлы писались наугад по клочкам информации с форумов. проблема осталась
Основная проблема курса - что ее пилили и пилят на общественных началах. А все остальное - это производные.
А надо, чтобы пилил закрытый НИИ, тогда всё по ГОСТам.
> выбран самодостаточный и компактный JavaScript-движок QuickJS,
> 2021-03-27:New release (Changelog)
для поддержки легаси заменили легаси на легаси
Интересно, почему не выбрали QJSEngine из состава Qt, который и является заменой устаревшему QtScript.
Чтобы не тянуть qdeclarative в зависимости, наверно
В оригинальной новости про это написано - он не позволяет перехватывать доступ к пропертям (точнее позволяет но очень криво и медленно - QtCreator резолвился в 2 раза медленее с QJSEngine бэкендом)
А еще может быть захотят дропнуть саму Qt.Оставят может только сами GUI конфигурялки на Qt.
И тогда аргумент жирных троллей о том что для сборки Qbs нужен Qt отводится сам собой. ))
qbs хотя-бы выглядит понятно. Я правда не понимаю зачем там императивный код - считаю что в файлах проектов достаточно перечня файлов исходников и параметров компиляции, заданных в удобном структурированном формате. В удобном как для человека, так и для IDE. Ну да ладно. По сравнению с make и cmake это все равно прогресс.
Только premake, только хардкор