forum.opennet.ru

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

Оглавление

Выпуск сборочного инструментария 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)

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

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ообщить модератору

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	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ообщить модератору