| 1.1, DEF (?), 22:22, 25/04/2023 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Дожили. Для сборки билд-тулзы нужен Qt. Скоро ядро Linux без GTK+ не будет собираться.
| | |
| |
| |
| |
| Часть нити удалена модератором |
| 4.20, EULA (?), 07:17, 26/04/2023 [ответить]
| –5 +/– |
Для сборки Cmake нужен Qt. Иначе Cmake-GUI не соберется
| | |
|
|
| 2.12, Вирт (?), 23:54, 25/04/2023 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Скоро ядро Linux без GTK+ не будет собираться.
Ну уже много лет с qt/gtk+ ядро конфигурируется намного легче.
Так как "make menuconfig" не такой удобный как "make gconfig/qconfig"
| | |
| |
| 3.45, Аноним (45), 18:09, 26/04/2023 [^] [^^] [^^^] [ответить]
| +/– | |
> "make menuconfig" не такой удобный как "make gconfig/qconfig"
А у меня всё с точностью до наоборот. Считаю самым удобным как раз menuconfig. Ну и oldconfig при минорных апдейтах.
| | |
|
|
| 1.3, InuYasha (??), 22:29, 25/04/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
К (счастью|сожалению) многие уже пересели на cmake, так что, увы. А ещё говорят, что и его уже абстрагировали. Но идея была интересная.
| | |
| |
| 2.5, Аноним (5), 22:41, 25/04/2023 [^] [^^] [^^^] [ответить]
| –1 +/– |
Уже дропнули и перешли на meson, на cmake всякая маргинальщина.
| | |
| |
| 3.35, Аноним (35), 12:53, 26/04/2023 [^] [^^] [^^^] [ответить]
| +/– |
Да, meson тоже напоминает Autotls и солянку из Perl^W Python скриптов.
Функционала больше, но вот сама реализация конечно печальная.
| | |
|
| 2.21, EULA (?), 07:19, 26/04/2023 [^] [^^] [^^^] [ответить]
| +/– |
Чтобы собрать проект для STM32 нужно всего чуть больше 1900 строк кода в CMAKE. Или чуть более 600 в QBS.
| | |
| |
| 3.22, Советский инженер (?), 07:22, 26/04/2023 [^] [^^] [^^^] [ответить]
| +/– |
 А про какие строки разговор? Ты считаеш строки проекта? Или еще и то что поставляется штатно с билдсистемой?
Если про юзерские, то как-то сильно много.
А если про все , то всем пофиг что там под капотом.
| | |
| |
| 4.23, EULA (?), 07:36, 26/04/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
> А про какие строки разговор? Ты считаеш строки проекта? Или еще и
> то что поставляется штатно с билдсистемой?
> Если про юзерские, то как-то сильно много.
> А если про все , то всем пофиг что там под капотом.
Про юзерские. Так как надо указать ручками смещение, опции кросскомпилятора, либы STM32 (HAL) для подключения устройств контроллера и подключенного оборудования и прочие параметры сборки.
Например, чтобы реализовать в проекте компиляцию либ работы microsd с FAT32 на контроллере STM32F103 нужно дописать около кполучтысячи строк кода в проект CMAKE.
Проект CMAKE осцилогрофа на STM32 Discovery более 600 килобайт весит, при том, что сама прошивка 256 КБ. Если это все не прописать, то в каждую либу нужно вносить ручками частоту работы процессора, частоту работы шины и т.д.
Да, на форумах есть готовые CMAKE файлы для камушков и либ к ним. Но это не штатный код CMAKE.
| | |
| |
| 5.24, Бывалый смузихлёб (?), 07:50, 26/04/2023 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Звучит как какой-то безумный онанизм вместо использования штук вроде стм32кубИде хотя бы в плане начальной генерации кода
А если стм-ина жирная, то даже с тактированиями писаниной можно просто задолбаться
| | |
| |
| 6.27, EULA (?), 08:51, 26/04/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
STM32Cube помогает настроить ножки самого камня, а не настроить то, что эти ножки будут пинать.
FAT32 можно поддерживать на SD-карте, USB-диске, flash-памяти. Либа одна, а настройки у нее разные, которые не задашь через кубик.
> то даже с тактированиями писаниной можно просто задолбаться
Вот поэтому и надо писать ооооооооооооочень много кода CMAKE.
| | |
| |
| 7.52, InuYasha (??), 11:58, 27/04/2023 [^] [^^] [^^^] [ответить]
| +/– |
Я не знаком со спецификой, но написать простой Makefile - ещё хуже будет?
| | |
|
| 6.60, kuzulis (?), 14:44, 27/04/2023 [^] [^^] [^^^] [ответить]
| +/– | |
Не не. Тут речь идет, как я понял, не о генерации с помощью кубика.
Вот сгенерили мы целиком сам ХАЛ и некоторую обвязку кубиком.
Теперь надо как то эти файлы подключить к проекту.
Путей два:
1. Или прописывать их и их зависимости ручками.
2. Или взять какое то готовое решение.
Вот для STM32 на гитхабе есть готовое решение на CMake. Где достаточно указать путь к директории с ХАЛ-ом, а уже отдельные компоненты: тип MCU, модули GPIO, таймеры, USB и прочее подключать через готовые штукенции, реализованные в решении, где пользователь даже не знает, какие файлы из ХАЛ подтянулись.
Поменяли тип MCU и автоматом потянулись из ХАЛ все нужное для этого MCU, красота.
То же самое можно сделать и для Qbs, просто нужно чтобы кто то взял на себя ответственность выложить это на гитхаб и поддерживать.
В этом случае на Qbs это будет выглядеть гооораздо прозрачнее, проще, красивее и т.п. чем на CMake.
| | |
|
|
|
|
|
| 1.6, Ванёк (?), 22:41, 25/04/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
make при грамотном использовании не оказывает ощутимого влияния на общее время сборки/пересборки проекта
| | |
| |
| 2.8, Аноним (8), 22:47, 25/04/2023 [^] [^^] [^^^] [ответить]
| +2 +/– |
в принципе, для хелловорлдов подойдет и однострочная команда gcc, размещенная в виде коммента в laba1.c. Что касается крупных проектов, то make им не подойдет.
| | |
| |
| |
| |
| 5.32, Совершенно другой аноним (?), 10:45, 26/04/2023 [^] [^^] [^^^] [ответить]
| +/– |
Насколько я знаю - perl там используется в основном для вспомогательных вещей, типа проверки патчей, работы со списками сопровождающих и тому подобных вещей, не влияющих на сам процесс сборки.
| | |
|
|
|
| 2.11, Аноним (11), 23:47, 25/04/2023 [^] [^^] [^^^] [ответить]
| +/– | |
Оказывает, к сожалению. Время пересборки (incremental build) вместе с make в сотни раз медленнее чем с qbs, meson, ninja, да почти что угодно (кроме всратого scons который умудряется делать инкрементные сборки медленнее чем make сделанный 40 лет назад).
К слову Qbs не замена make, а скорее замена meson+ninja, cmake+make, SCons, MSBuild autotools+make и вот такого прочего. т.е. не просто сборка, а полный комбайн.
Я не агитирую переходить на Qbs, к сожалению он сильно отстает по фичам от cmake а по интеграции с IDE от вообще чего угодно (кроме qt creator на все остальное забей).
| | |
| |
| |
| 4.33, Ванёк (?), 10:55, 26/04/2023 [^] [^^] [^^^] [ответить]
| +/– |
Да, именно так, всё упирается в компилятор, а не в make или что-то ещё.
| | |
| 4.36, Аноним (36), 15:16, 26/04/2023 [^] [^^] [^^^] [ответить]
| +4 +/– | |
Для полной пересборки да, все упирается в производительность компилятора.
Но при инкрементальной сборке, когда из сотен файлов поменялся один-два, перекомпилироваться должны только эти два файла и после этого запустить линковщики только для измененных либ. Но для того, чтобы понять, какие файлы поменялись и как оптимально пересобрать/перелинковать только нужные изменения, система сборки должна построить дерево зависимостей и перешерстить все эти сотни файлов. А потому она должна быть очень быстрой.
Так что, если просто брать готовый сторонний проект и немодифицируя его собирать, то, в принципе, без разницы, какая у него система сборки. А вот если быть разработчиком этого проекта, то быстрая инкрементальная сборка очень важна.
| | |
| |
| 5.53, InuYasha (??), 12:01, 27/04/2023 [^] [^^] [^^^] [ответить]
| +/– |
По-моему, сравнивать даты изменения *.c и *.obj умел ещё make - разве нет?
| | |
|
| 4.38, Аноним (38), 15:50, 26/04/2023 [^] [^^] [^^^] [ответить]
| +/– |
>> Время пересборки (incremental build)
> скорость сборки зависит не от инструментария автоматизации сборки, а от компилятора
По вашей ссылке речь идёт о чистой сборке, а начальное сообщение — про инкрементальную сборку, которая нужна разработчикам десятки и сотни раз в день.
Для make совершенно типично долго обходить все каталоги, чтобы через 10+ секунд скомпилировать и перелинковать один файл. Для больших проектов это просто ад.
| | |
| |
| 5.43, Ванёк (?), 17:19, 26/04/2023 [^] [^^] [^^^] [ответить]
| +/– |
Пересборку make делает очень быстро. У меня каждый раз делается замер общего времени компиляции/сборки, времени компиляции каждого модуля, времени линковки и прочего. Причём сценарии сборки make довольно большие (более 1500 строк чистого кода - это уже после вычета комментариев и пустых строк) и используется Perl для вспомогательных целей. Вывод следующий: как для полной сборки проекта, так и для частичной пересборки, ситуация примерно одна и та же, а именно: практически всё время затрачивается на работу компилятора gcc/clang, а всё остальное (make, линковщик...) занимает очень незначительное время, уменьшение которого на общее время как-то существенно повлиять не может.
| | |
|
|
| 3.34, Ванёк (?), 11:11, 26/04/2023 [^] [^^] [^^^] [ответить]
| +/– |
Время сборки при использовании make практически такое же, как при использовании любого другого инструментария для организации сборки. Всегда замеряю общее время сборки проекта, каждого модуля в отдельности, и всегда оказывается, что практически всё время сборки тратится на работу компилятора gcc/clang (clang обычно чуть быстрее gcc), а не make. Это, конечно, при условии грамотного написания сценариев make. Всё, что вы можете выиграть от перехода на более новые системы сборки - это десятые доли секунды.
| | |
| |
| 4.42, Аноним (38), 17:18, 26/04/2023 [^] [^^] [^^^] [ответить]
| +/– | |
> Всё, что вы можете выиграть от перехода на более новые системы сборки - это десятые доли секунды.
Всё, что могут выиграть пользователи — это проценты, да. А разработчки могут каждый день экономить по пол часа. Вообще — тут как с git.
Ситуация похожа на то, что Linus говорил про git (https://www.youtube com/watch?v=4XpnKHJAok8&t=3287s).
Разница не просто «быстрее или медленнее».
Если сборка занимает секунду, то в случае сомнений можно нажать build и посмотреть результат.
А с make нужно ждать 10-20-30 секунд, и это всё меняет.
| | |
| |
| 5.44, Ванёк (?), 17:25, 26/04/2023 [^] [^^] [^^^] [ответить]
| +/– |
Замеры времени показывают, что практически всё время затрачивается на работу компилятора. Make, линковщик и прочее занимает максимум 5% времени в худшем случае. Если у кого-то иначе, смотрите, что не так с вашими сценариями сборки make, изучите make лучше - у него много опций и возможностей которые надо понимать, чтобы всё хорошо работало. Также надо понимать опции компиляторов gcc/clang, некоторые из которых непосредственно взаимосвязаны с работой make.
| | |
| |
| 6.46, Аноним (38), 19:59, 26/04/2023 [^] [^^] [^^^] [ответить] | +/– | Вы понимаете, что значит incremental build Давайте напомню это повторная сборк... большой текст свёрнут, показать | | |
| |
| 7.47, Ванёк (?), 21:40, 26/04/2023 [^] [^^] [^^^] [ответить]
| +/– |
Никто каждый раз не перекомпилирует весь проект. Это обычный режим работы. Все в курсе об этом режиме. Для этого режима и предназначен make и работает он очень быстро. Если в проекте нет изменений, то на среднем проекте проверка всего и вся занимает десятые доли секунды. У меня он работает так. Всё работает быстро, и ничего не тормозит. При этом сценарии make не маленькие - более 1500 строк (это уже за вычетом комментариев и пустых строк).
| | |
| 7.48, Ванёк (?), 22:03, 26/04/2023 [^] [^^] [^^^] [ответить]
| +/– |
Выше уже приводили ссылку, где сравнивается производительность make и ninja, которая разрабатывалась как улучшенная и ускоренная альтернатива make: https://hamelot.io/programming/make-vs-ninja-performance-comparison/
Это правдивые данные. По факту разница в производительности между ними очень незначительная, как для полной, так и для частичной пересборки проекта, хотя для частичной пересборки она таки есть, но абсолютно некритичная - десятые доли секунды. То есть для тех, у кого уже есть отработанные годами сценарии сборки make, переходить на что-то другое смысла никакого нет.
| | |
|
|
|
|
| 3.57, kuzulis (?), 14:21, 27/04/2023 [^] [^^] [^^^] [ответить]
| +/– | |
> (кроме qt creator на все остальное забей).
Есть же еще плагин для VSCode. ))
| | |
|
|
| 1.15, Аноним (15), 03:44, 26/04/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
основная проблема qbs была в отсутствии документации, qbs-файлы писались наугад по клочкам информации с форумов. проблема осталась
| | |
| 1.17, Аноним (15), 03:49, 26/04/2023 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
> выбран самодостаточный и компактный JavaScript-движок QuickJS,
> 2021-03-27:
New release (Changelog)
для поддержки легаси заменили легаси на легаси
| | |
| 1.18, Аноним (18), 04:37, 26/04/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Интересно, почему не выбрали QJSEngine из состава Qt, который и является заменой устаревшему QtScript.
| | |
| |
| 2.37, ABBAPOH (ok), 15:49, 26/04/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
 В оригинальной новости про это написано - он не позволяет перехватывать доступ к пропертям (точнее позволяет но очень криво и медленно - QtCreator резолвился в 2 раза медленее с QJSEngine бэкендом)
| | |
| 2.58, kuzulis (?), 14:29, 27/04/2023 [^] [^^] [^^^] [ответить]
| +/– | |
А еще может быть захотят дропнуть саму Qt.
Оставят может только сами GUI конфигурялки на Qt.
И тогда аргумент жирных троллей о том что для сборки Qbs нужен Qt отводится сам собой. ))
| | |
|
| 1.25, nc (ok), 08:21, 26/04/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 qbs хотя-бы выглядит понятно. Я правда не понимаю зачем там императивный код - считаю что в файлах проектов достаточно перечня файлов исходников и параметров компиляции, заданных в удобном структурированном формате. В удобном как для человека, так и для IDE. Ну да ладно. По сравнению с make и cmake это все равно прогресс.
| | |
|
