Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Выпуск сборочного инструментария Qbs 2.0, opennews (?), 25-Апр-23, (0) [смотреть все] Дожили Для сборки билд-тулзы нужен Qt Скоро ядро Linux без GTK не будет собир, DEF (?), 22:22 , 25-Апр-23, (1) –1 // Для сборки Cmake нужен Qt Иначе Cmake-GUI не соберется, EULA (?), 07:17 , 26-Апр-23, (20) –5 Ну уже много лет с qt gtk ядро конфигурируется намного легче Так как make menu, Вирт (?), 23:54 , 25-Апр-23, (12) +1 // Попробуй в vi Тебе понравится, 1 (??), 10:33 , 26-Апр-23, (31) // Я лучше в плейере Там хоть музыка, а не просто писк , Аноним (40), 16:20 , 26-Апр-23, (40) +1 А у меня всё с точностью до наоборот Считаю самым удобным как раз menuconfig Н, Аноним (45), 18:09 , 26-Апр-23, (45) GTK надо писать именно так GTK , без знака https www opennet ru opennews , Аноним (40), 16:17 , 26-Апр-23, (39) К счастью 124 сожалению многие уже пересели на cmake, так что, увы А ещё гов, InuYasha (??), 22:29 , 25-Апр-23, (3) // Уже дропнули и перешли на meson, на cmake всякая маргинальщина , Аноним (5), 22:41 , 25-Апр-23, (5) –1 // Да, meson тоже напоминает Autotls и солянку из Perl W Python скриптов Функционал, Аноним (35), 12:53 , 26-Апр-23, (35) Окей, так и запишем телеграм - маргинальщина , InuYasha (??), 11:56 , 27-Апр-23, (51) // Именно так , Аноним (63), 13:42 , 04-Май-23, (63) Чтобы собрать проект для STM32 нужно всего чуть больше 1900 строк кода в CMAKE , EULA (?), 07:19 , 26-Апр-23, (21) // А про какие строки разговор Ты считаеш строки проекта Или еще и то что поставл, Советский инженер (?), 07:22 , 26-Апр-23, (22) // Про юзерские Так как надо указать ручками смещение, опции кросскомпилятора, либ, EULA (?), 07:36 , 26-Апр-23, (23) +1 Звучит как какой-то безумный онанизм вместо использования штук вроде стм32кубИде, Бывалый смузихлёб (?), 07:50 , 26-Апр-23, (24) +1 STM32Cube помогает настроить ножки самого камня, а не настроить то, что эти ножк, EULA (?), 08:51 , 26-Апр-23, (27) +1 Я не знаком со спецификой, но написать простой Makefile - ещё хуже будет , InuYasha (??), 11:58 , 27-Апр-23, (52) Вроде не хуже Но и не лучше QBS-ом проще , EULA (?), 13:20 , 27-Апр-23, (55) Тут основной профит от Qbs в том, что он передает в IDE всю инфу о собираемом пр, kuzulis (?), 14:18 , 27-Апр-23, (56) Т е тут вмешивается извечная проблема борьбы ИДЕ с проектом и CLI Я просто не п, InuYasha (??), 14:42 , 27-Апр-23, (59) ИМХО, сама ИДЕ не должна ничего знать о том как и что и каким компилятором собир, kuzulis (?), 14:53 , 27-Апр-23, (61) Ну, тогда тебе и Kate - IDE А мне нужен годный дебуггер, дизасёмблер, графопост, InuYasha (??), 14:57 , 27-Апр-23, (62) Не не Тут речь идет, как я понял, не о генерации с помощью кубика Вот сгенерили, kuzulis (?), 14:44 , 27-Апр-23, (60) make при грамотном использовании не оказывает ощутимого влияния на общее время с, Ванёк (?), 22:41 , 25-Апр-23, (6) +1 // в принципе, для хелловорлдов подойдет и однострочная команда gcc, размещенная в , Аноним (8), 22:47 , 25-Апр-23, (8) +2 // Ядро Linux достаточно крупный проект , Совершенно другой аноним (?), 08:45 , 26-Апр-23, (26) // Что то тут https www kernel org doc html v4 10 process changes html список нео, Советский инженер (?), 10:05 , 26-Апр-23, (29) Насколько я знаю - perl там используется в основном для вспомогательных вещей, т, Совершенно другой аноним (?), 10:45 , 26-Апр-23, (32) Оказывает, к сожалению Время пересборки incremental build вместе с make в сот, Аноним (11), 23:47 , 25-Апр-23, (11)   // В сотни раз -- сильное преувеличение https hamelot io programming make-vs-n, Аноним (14), 00:20 , 26-Апр-23, (14) +1   // Да, именно так, всё упирается в компилятор, а не в make или что-то ещё , Ванёк (?), 10:55 , 26-Апр-23, (33)   Для полной пересборки да, все упирается в производительность компилятора Но при , Аноним (36), 15:16 , 26-Апр-23, (36) +4   По-моему, сравнивать даты изменения c и obj умел ещё make - разве нет , InuYasha (??), 12:01 , 27-Апр-23, (53)   Почитал остальной ваш тред - можете не отвечать D, InuYasha (??), 12:03 , 27-Апр-23, (54)   По вашей ссылке речь идёт о чистой сборке, а начальное сообщение 8212 про инк, Аноним (38), 15:50 , 26-Апр-23, (38)   Пересборку make делает очень быстро У меня каждый раз делается замер общего вре, Ванёк (?), 17:19 , 26-Апр-23, (43)   Время сборки при использовании make практически такое же, как при использовании , Ванёк (?), 11:11 , 26-Апр-23, (34)   // Всё, что могут выиграть пользователи 8212 это проценты, да А разработчки мог, Аноним (38), 17:18 , 26-Апр-23, (42)   Замеры времени показывают, что практически всё время затрачивается на работу ком, Ванёк (?), 17:25 , 26-Апр-23, (44)   Вы понимаете, что значит incremental build Давайте напомню это повторная сборка, Аноним (38), 19:59 , 26-Апр-23, (46)   Никто каждый раз не перекомпилирует весь проект Это обычный режим работы Все в, Ванёк (?), 21:40 , 26-Апр-23, (47)   Выше уже приводили ссылку, где сравнивается производительность make и ninja, кот, Ванёк (?), 22:03 , 26-Апр-23, (48)   Есть же еще плагин для VSCode , kuzulis (?), 14:21 , 27-Апр-23, (57)   когда уже сборочная система на расте , Я (??), 23:24 , 25-Апр-23, (10) // давно уже есть https www opennet ru opennews art shtml num 58933, Вирт (?), 23:56 , 25-Апр-23, (13) основная проблема qbs была в отсутствии документации, qbs-файлы писались наугад , Аноним (15), 03:44 , 26-Апр-23, (15) // Основная проблема курса - что ее пилили и пилят на общественных началах А все о, Советский инженер (?), 10:07 , 26-Апр-23, (30) // А надо, чтобы пилил закрытый НИИ, тогда всё по ГОСТам , Аноним (40), 16:27 , 26-Апр-23, (41) New release Changelog для поддержки легаси заменили легаси на легаси, Аноним (15), 03:49 , 26-Апр-23, (17) –1 Интересно, почему не выбрали QJSEngine из состава Qt, который и является заменой, Аноним (18), 04:37 , 26-Апр-23, (18) // Чтобы не тянуть qdeclarative в зависимости, наверно, Аноним (19), 07:11 , 26-Апр-23, (19) В оригинальной новости про это написано - он не позволяет перехватывать доступ к, ABBAPOH (ok), 15:49 , 26-Апр-23, (37) +1 А еще может быть захотят дропнуть саму Qt Оставят может только сами GUI конфигу, kuzulis (?), 14:29 , 27-Апр-23, (58) qbs хотя-бы выглядит понятно Я правда не понимаю зачем там императивный код - с, nc (ok), 08:21 , 26-Апр-23, (25) Только premake, только хардкор, Аноним (28), 09:09 , 26-Апр-23, (28) 1,3,6,10,15,17,18,25,28

Сообщения

[Сортировка по времени | RSS]

	11. "Выпуск сборочного инструментария Qbs 2.0"	+/–
	Сообщение от Аноним (11), 25-Апр-23, 23:47
	Оказывает, к сожалению. Время пересборки (incremental build) вместе с make в сотни раз медленнее чем с qbs, meson, ninja, да почти что угодно (кроме всратого scons который умудряется делать инкрементные сборки медленнее чем make сделанный 40 лет назад). К слову Qbs не замена make, а скорее замена meson+ninja, cmake+make, SCons, MSBuild autotools+make и вот такого прочего. т.е. не просто сборка, а полный комбайн. Я не агитирую переходить на Qbs, к сожалению он сильно отстает по фичам от cmake а по интеграции с IDE от вообще чего угодно (кроме qt creator на все остальное забей).
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	14. "Выпуск сборочного инструментария Qbs 2.0"	+1 +/–
	Сообщение от Аноним (14), 26-Апр-23, 00:20
	"В сотни раз" -- сильное преувеличение. https://hamelot.io/programming/make-vs-ninja-performance-com.../ И скорость сборки зависит не от инструментария автоматизации сборки, а от компилятора -- он требует больше всего ресурсов (любых, не важно, ЦП, памяти или I/O), поэтому производительность упирается именно в него.
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Выпуск сборочного инструментария Qbs 2.0"	+/–
	Сообщение от Ванёк (?), 26-Апр-23, 10:55
	Да, именно так, всё упирается в компилятор, а не в make или что-то ещё.
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Выпуск сборочного инструментария Qbs 2.0"	+4 +/–
	Сообщение от Аноним (36), 26-Апр-23, 15:16
	Для полной пересборки да, все упирается в производительность компилятора. Но при инкрементальной сборке, когда из сотен файлов поменялся один-два, перекомпилироваться должны только эти два файла и после этого запустить линковщики только для измененных либ.  Но для того, чтобы понять, какие файлы поменялись и как оптимально пересобрать/перелинковать только нужные изменения, система сборки должна построить дерево зависимостей и  перешерстить все эти сотни файлов. А потому она должна быть очень быстрой. Так что, если просто брать готовый сторонний проект и немодифицируя его собирать, то, в принципе, без разницы, какая у него система сборки. А вот если быть разработчиком этого проекта, то быстрая инкрементальная сборка очень важна.
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	53. "Выпуск сборочного инструментария Qbs 2.0"	+/–
	Сообщение от InuYasha (??), 27-Апр-23, 12:01
	По-моему, сравнивать даты изменения *.c и *.obj умел ещё make - разве нет?
	Ответить | Правка | Наверх | Cообщить модератору

	54. "Выпуск сборочного инструментария Qbs 2.0"	+/–
	Сообщение от InuYasha (??), 27-Апр-23, 12:03
	Почитал остальной ваш тред - можете не отвечать :D
	Ответить | Правка | Наверх | Cообщить модератору

	38. "Выпуск сборочного инструментария Qbs 2.0"	+/–
	Сообщение от Аноним (38), 26-Апр-23, 15:50
	>> Время пересборки (incremental build) > скорость сборки зависит не от инструментария автоматизации сборки, а от компилятора По вашей ссылке речь идёт о чистой сборке, а начальное сообщение — про инкрементальную сборку, которая нужна разработчикам десятки и сотни раз в день. Для make совершенно типично долго обходить все каталоги, чтобы через 10+ секунд скомпилировать и перелинковать один файл. Для больших проектов это просто ад.
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	43. "Выпуск сборочного инструментария Qbs 2.0"	+/–
	Сообщение от Ванёк (?), 26-Апр-23, 17:19
	Пересборку make делает очень быстро. У меня каждый раз делается замер общего времени компиляции/сборки, времени компиляции каждого модуля, времени линковки и прочего. Причём сценарии сборки make довольно большие (более 1500 строк чистого кода - это уже после вычета комментариев и пустых строк) и используется Perl для вспомогательных целей. Вывод следующий: как для полной сборки проекта, так и для частичной пересборки, ситуация примерно одна и та же, а именно: практически всё время затрачивается на работу компилятора gcc/clang, а всё остальное (make, линковщик...) занимает очень незначительное время, уменьшение которого на общее время как-то существенно повлиять не может.
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Выпуск сборочного инструментария Qbs 2.0"	+/–
	Сообщение от Ванёк (?), 26-Апр-23, 11:11
	Время сборки при использовании make практически такое же, как при использовании любого другого инструментария для организации сборки. Всегда замеряю общее время сборки проекта, каждого модуля в отдельности, и всегда оказывается, что практически всё время сборки тратится на работу компилятора gcc/clang (clang обычно чуть быстрее gcc), а не make. Это, конечно, при условии грамотного написания сценариев make. Всё, что вы можете выиграть от перехода на более новые системы сборки - это десятые доли секунды.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	42. "Выпуск сборочного инструментария Qbs 2.0"	+/–
	Сообщение от Аноним (38), 26-Апр-23, 17:18
	> Всё, что вы можете выиграть от перехода на более новые системы сборки - это десятые доли секунды. Всё, что могут выиграть пользователи — это проценты, да. А разработчки могут каждый день экономить по пол часа. Вообще — тут как с git. Ситуация похожа на то, что Linus говорил про git (https://www.youtube com/watch?v=4XpnKHJAok8&t=3287s). Разница не просто «быстрее или медленнее». Если сборка занимает секунду, то в случае сомнений можно нажать build и посмотреть результат. А с make нужно ждать 10-20-30 секунд, и это всё меняет.
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Выпуск сборочного инструментария Qbs 2.0"	+/–
	Сообщение от Ванёк (?), 26-Апр-23, 17:25
	Замеры времени показывают, что практически всё время затрачивается на работу компилятора. Make, линковщик и прочее занимает максимум 5% времени в худшем случае. Если у кого-то иначе, смотрите, что не так с вашими сценариями сборки make, изучите make лучше - у него много опций и возможностей которые надо понимать, чтобы всё хорошо работало. Также надо понимать опции компиляторов gcc/clang, некоторые из которых непосредственно взаимосвязаны с работой make.
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Выпуск сборочного инструментария Qbs 2.0"	+/–
	Сообщение от Аноним (38), 26-Апр-23, 19:59
	> Замеры времени показывают, что практически всё время затрачивается на работу компилятора. Вы понимаете, что значит incremental build? Давайте напомню: это повторная сборка без очистки сборочной директории. Допустим, в проекте 100 C++ файлов. Разработчики, как правило, редактируют их по одному. И вот в случае, если разработчик что-то делает в одном файле и периодически собирает проект для проверки, то компилируются не 100 файлов, а один. И в этом случае проявляется неэффективность сценариев make в работе с файлами. Большая часть времени в такой сборке уходит не на компиляцию, а на проверку того, что 99 файлов компилировать не надо. > линковщик и прочее занимает максимум 5% времени в худшем случае Включите LTCG или отладку и линковка сразу займёт больше времени. Но смысл в том, что в инкрементальных сборках время работы make куда больше 5% и вполне бывает 50% и даже 90%. Вот делает разработчик, например, тест для какого-нибудь toolkit — Qt или GTK. Запуск make даже без изменившихся файлов займёт десятки секунд, а потом компиляция+линковка теста ещё 1-3 секунды.
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Выпуск сборочного инструментария Qbs 2.0"	+/–
	Сообщение от Ванёк (?), 26-Апр-23, 21:40
	Никто каждый раз не перекомпилирует весь проект. Это обычный режим работы. Все в курсе об этом режиме. Для этого режима и предназначен make и работает он очень быстро. Если в проекте нет изменений, то на среднем проекте проверка всего и вся занимает десятые доли секунды. У меня он работает так. Всё работает быстро, и ничего не тормозит. При этом сценарии make не маленькие - более 1500 строк (это уже за вычетом комментариев и пустых строк).
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Выпуск сборочного инструментария Qbs 2.0"	+/–
	Сообщение от Ванёк (?), 26-Апр-23, 22:03
	Выше уже приводили ссылку, где сравнивается производительность make и ninja, которая разрабатывалась как улучшенная и ускоренная альтернатива make: https://hamelot.io/programming/make-vs-ninja-performance-com.../ Это правдивые данные. По факту разница в производительности между ними очень незначительная, как для полной, так и для частичной пересборки проекта, хотя для частичной пересборки она таки есть, но абсолютно некритичная - десятые доли секунды. То есть для тех, у кого уже есть отработанные годами сценарии сборки make, переходить на что-то другое смысла никакого нет.
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	57. "Выпуск сборочного инструментария Qbs 2.0"	+/–
	Сообщение от kuzulis (?), 27-Апр-23, 14:21
	> (кроме qt creator на все остальное забей). Есть же еще плагин для VSCode. ))
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема