The OpenNET Project / Index page

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



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

Оглавление

Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4, opennews (?), 24-Окт-17, (0) [смотреть все]

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


28. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"  +2 +/
Сообщение от Аноним (-), 24-Окт-17, 09:34 
https://www.opennet.ru/opennews/art.shtml?num=47031

> По сравнению с Autotools время сборки GTK+ сократилось в три раза. На пути к переходу на Meson также находится проект Mesa - сборка Mesa при помощи Meson оказалась в 4 раза быстрее при первом запуске и в 10 раз быстрее при повторном.

Здесь что-то не чисто. Сборка - это вызовы компилятора/компоновщика, время не зависит от "системы сборки".

Ответить | Правка | Наверх | Cообщить модератору

32. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"  +/
Сообщение от Аноним (-), 24-Окт-17, 09:57 
В случае с autocrap — это ещё и прогон 100500 тестовых компиляций для проверки наличия тех или иных либ, функций, заголовков и т. п.
Ответить | Правка | Наверх | Cообщить модератору

42. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"  +2 +/
Сообщение от Аноним (-), 24-Окт-17, 10:42 
но автотесты же не должны входить во время сборки...
Ответить | Правка | Наверх | Cообщить модератору

63. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"  +/
Сообщение от Orduemail (ok), 24-Окт-17, 12:21 
Должны или не должны... Какая разница, если они входят? Ну, ты попробуй собрать gtk без прогона автотестов и увидишь сам.
Ответить | Правка | Наверх | Cообщить модератору

79. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"  +/
Сообщение от Аноним (-), 24-Окт-17, 13:41 
> но автотесты же не должны входить во время сборки...

Во время сборки не проходят. Проходят во время конфигурации. Тебе ./configure && make запускать доводилось? Загляни как-нибудь в config.log и ужаснись.

Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

43. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"  –1 +/
Сообщение от Аноним (-), 24-Окт-17, 10:49 
Давайте еще говорить, что после перехода с gzip на xz время сборки уменьшилось, так как теперь загрузка быстрее.
Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

83. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"  +/
Сообщение от Mihail Zenkov (ok), 24-Окт-17, 14:07 
> Здесь что-то не чисто.

В новости ошибка - там замеры были не на mesa, а на libdrm. Библиотека libdrm небольшая и запуск configure идет дольше сборки. Для больших библиотек типа mesa выигрыш будет максимум 10% (и то, только если сам meson окажется быстрее configure в десять раз).

Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

115. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"  +/
Сообщение от dhamp (?), 24-Окт-17, 18:28 
сравнивают скорее всего
$meson buildir && cd builddir && ninja
c
$./configure && make

по сути сравнение
make -j1 vs ninja -j$(nproc)
Сравнение времени выполнения meson и configure в большистве случаев бесполезно, т.к. сборка занимает по времени много больше.

"Корректность" сравнения зашкаливает.

Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

130. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"  +1 +/
Сообщение от dhamp (?), 24-Окт-17, 20:45 
Просто для примера сборка одного проекта.
cmake + ninja 1917.45s user 133.06s system 1013% cpu 3:22.26 total
cmake + make -j$(nproc) 1890.67s user 141.66s system 941% cpu 3:35.91 total

Профит сомнителен.

Ответить | Правка | Наверх | Cообщить модератору

132. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"  +2 +/
Сообщение от Orduemail (ok), 24-Окт-17, 20:51 
> сравнивают скорее всего

Нет. Если они и хитрят, то с выбором железа для сборки.

> сборка занимает по времени много больше.

GTK сваян на C. Компиляторы C просто реактивные, по сравнению с некоторыми. При этом, в отличие от configure, процесс собственно компиляции отлично ускоряется увеличением числа ядер. А вот ./configure будет тормозить на 8-ядерном процессоре ровно так же, как он тормозил на одноядерном. Если в проекте несколько скриптов ./configure, то каждый из них будет тормозить, и делать они это будут по-очереди, занимая ровно одно ядро.

Ещё интереснее, когда distcc используешь, чтобы собирать свою генту в офисе, где удалось тихим вечерком два десятка офисных компов в сборочный кластер собрать, чтобы по-бырому раскатать дженту на не очень шустром ноуте. Там этот configure начинает откровенно выбешивать. Вообще складывается ощущение, что вся сборка состоит из бесконечных вызовов ./configure и бесконечных проверок того, что char занимает 1 байт, "может что изменилось с предыдущего раза и char подрос?". Весь этот вывод configure уже заучен наизусть, я его сам могу на клавиатуре набрать с закрытыми глазами, ан нет, автотулзы продолжают долбить в одну и ту же точку.

А, и да, я отмечу, что так бесили они меня более десяти лет назад, и те два десятка офисных компов были селерончиками в которых, если мне память не изменяет, стояли смешные 256Mb оперативки. Что будет сейчас, если это не селерончики, а какие-нибудь двух-четырёх ядерные монстры, я вообще с трудом представляю. Секунд десять думает emerge, потом ещё тридцать секунд configure, после чего пять секунд компиляции, две секунды линковки, и ещё секунд десять на emerge. Что-нибудь в этом стиле. Реально погреться такому кластеру удастся только на всяких там файрфоксах да опенофисах.

Ответить | Правка | К родителю #115 | Наверх | Cообщить модератору

143. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"  +1 +/
Сообщение от Mihail Zenkov (ok), 25-Окт-17, 09:55 
> Если в проекте
> несколько скриптов ./configure, то каждый из них будет тормозить, и делать
> они это будут по-очереди, занимая ровно одно ядро.

Зависит от проекта. Если в проекте собираются одновременно несколько подпроектов/библиотек, то не кто не запрещает во время компиляции одного запустить configure у другого. AFAIK gcc так и делает.

> бесконечных проверок того, что char
> занимает 1 байт, "может что изменилось с предыдущего раза и char
> подрос?". Весь этот вывод configure уже заучен наизусть, я его сам
> могу на клавиатуре набрать с закрытыми глазами, ан нет, автотулзы продолжают
> долбить в одну и ту же точку.

Учить нужно не вывод, а маны :) Я сам так много лет смотрел и думал - сколько можно проверять char? Наконец залез в доки и нашел:
    https://www.gnu.org/software/automake/manual/html_node/confi...
    https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/a...
    https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/a...

Сделал программу, которая собирает config.cache после сборки. Потом запускаю вторую программу, которая анализирует все имеющиеся config.cache и создает config.site, в который попадают только те переменные, которые имеют одно и тоже значение во всех config.cache.

Тестировал на lfs, но большого выигрыша не увидел (собираю на четырех ядрах). Возможно на blfs выигрыш будут более значимым (особенно на Xorg - там реально в раза два быстрее должно получится).

Ответить | Правка | Наверх | Cообщить модератору

159. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"  +/
Сообщение от Orduemail (ok), 25-Окт-17, 19:35 
> Сделал программу, которая собирает config.cache после сборки. Потом запускаю вторую программу, которая анализирует все имеющиеся config.cache и создает config.site, в который попадают только те переменные, которые имеют одно и тоже значение во всех config.cache.

И это работает? Ну, в том смысле, что между генерацией config.cache и следующим запуском ./configure произойдёт установка пакета, которая вообще-то может инвалидировать какие-то переменные в этом config.cache. Кстати да, я даже конкретный сценарий могу предложить. Ставим софтину с опциональной зависимостью от gtk. Её configure проверяет наличие gtk, не находит его в системе, вносит в config.cache запись о том, что gtk в системе нет. Ставим gtk. А теперь ставим софтину с жёсткой зависимостью от gtk. Теперь configure заглядывает в config.site, находит, что gtk в системе нету, и отказывается генерировать Makefile.

Другое дело, что может если собрать переменные, которые стопудов никогда не меняются (скажем, относящиеся к проверкам libc и cc) и один раз их сложить в config.site...

Кроме того, тут встаёт проблема, что если я в процессе пересборки системы занимаюсь вознёй с этими кешами, то я встраиваю в процесс пересборки ещё более тормозной этап, нежели ./configure -- себя. Таким образом, чтобы с этого получить хоть какой-нибудь бонус по скорости, надо это всё автоматизировать, а для этого надо лезть в портажи и перелопачивать eclass'ы. В идеальном случае будет достаточно изменить один eclass, но я не верю в идеальные случаи. Скорее всего придётся поменять несколько eclass'ов, и ещё процентов 10 ебилдов всё равно будут всё делать по-своему. То есть, здравый баланс между оптимизмом и пессимизмом предсказывает часов 40-80 на перепиливание портажей. _Моих_ 40-80 часов, а не сборочного кластера. Причём с неопределённым результатом: может быть не удастся сделать так, чтобы config.site не создавал бы помех, и не приходилось бы ещё и вручную периодически вмешиваться, чтобы сборка продолжалась бы.

Ответить | Правка | Наверх | Cообщить модератору

162. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"  +/
Сообщение от Mihail Zenkov (ok), 25-Окт-17, 21:44 
>> Сделал программу, которая собирает config.cache после сборки. Потом запускаю вторую программу, которая анализирует все имеющиеся config.cache и создает config.site, в который попадают только те переменные, которые имеют одно и тоже значение во всех config.cache.
> И это работает?

Собираем всю систему и попутно собираем все config.cache. Генерируем config.site. Повторная сборка системы будет гораздо быстрее.

Но да, все это можно легко сломать.

> Другое дело, что может если собрать переменные, которые стопудов никогда не меняются
> (скажем, относящиеся к проверкам libc и cc) и один раз их
> сложить в config.site...

Таких переменных не так уж и много. Выигрыш будет не большой.

Тут нужна методика четко позволяющая отделить переменные и константы для конкретно вашей системы. Есть у меня мысль попробовать исключить все переменные, которые используются менее трех раз.

Но в итоге и встает вопрос, а стоит ли оно того?

>  Таким образом, чтобы с этого получить хоть какой-нибудь бонус по скорости, надо это всё автоматизировать, а для этого надо лезть в портажи и перелопачивать eclass'ы.

У меня своя система сборки. На все правки, включая написание программ для сборки и обработки config.cache ушло 3-4 часа.

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

С другой стороны, если появилась проблема - отключаем config.site и собираем как обычно. Вроде ничего сложного.

Вообще нужно поработать с этим какое-то время, чтобы набрать некоторую статистику по отказам.

Ответить | Правка | Наверх | Cообщить модератору

164. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"  +/
Сообщение от Orduemail (ok), 26-Окт-17, 03:05 
> У меня своя система сборки. На все правки, включая написание программ для
> сборки и обработки config.cache ушло 3-4 часа.

Поддержание своей системы сборки будет требовать гораздо больше времени. Все эти задачи связанные с обсчётом депендансов, выкачиванием сорцов нужных версий из нужных мест по нужным протоколам, обходом всех специальных случаев... В gentoo это решается написанием ебилда на каждый пакет. Но, вот, допустим, я пользуюсь оверлеем rust, чтобы иметь в системе расты разных версий, причём хоть самых-самых nightly. Иногда это требует правки ебилдов. Но мне приходилось отказываться от внесения каких-то изменений, потому что это были изменения, которые не примут в "апстрим", а самостоятельно поддерживать эти изменения я не готов совершенно. Внести и отправить пулл-реквест -- легко: поигрался с ebuild, выполняя работу emerge поэтапно, создал патч, оттестил его, отправил и забыл. А вот следить за актуальностью моего форка оверлея -- не, спасибо, вот заняться мне больше нечем. Если что, я могу и потерпеть пару месяцев, а там проблема тем или иным способом разрешится.

> С другой стороны, если появилась проблема - отключаем config.site и собираем как
> обычно. Вроде ничего сложного.

Я в генту последнее время избегаю использовать keyword'ы типа ~amd64, потому что практика показывает, что эти флаги накапливаются в /etc/portage, и лет через десять это кончается тем, что либо emerge не может обсчитать зависимости, либо сборка внезапно обламывается в какой-то момент, и если месяц не обновлял мир, то потом такое обновление займёт пару часов (моего времени, не процессорного) в то, чтобы найти причины отказов и устранить их. И хорошо, если все эти причины выявятся на этапе обсчёта депендансов, а не начнут выскакивать в рандомные моменты сборки, в течение нескольких часов работы emerge. В общем, приемлимый для меня компромисс между надёжностью и конфигурабельностью со временем смещается в сторону надёжности.

Тем более надёжность важна, если мы создаём не наколенное решение для применения на локалхосте, а вполне себе системное решение, у которого будут сотни и тысячи пользователей.

Если мы попытаемся этот config.site впилить, например, в emerge и дополнить этим костылём с рестартом сборки, то встанет вопрос: как мы можем выяснить программно, что сборка обломалась из-за косяков с config.site? Или после каждого облома мы на всякий случай будем удалять config.site и делать рестарт -- а вдруг прокатит?

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

Да, на самом деле эта вероятность получить проблемы и есть основная претензия к autotools.

autotools -- это такое хакерское решение: минимумом усилий максимум результата. Но *nix в своём развитии ушёл за границы возможного для autotools, требования изменились. Изменилась и среда: сегодня нет необходимости тщательно проверять компиляторы C, потому что времена, когда каждый компилятор C имел свои собственные нюансы реализации, ушли в прошлое (почему C не считался кроссплатформенным языком в 80-е, да и в 90-е в общем-то? Как раз потому, что написать код, который скомпилируется двумя разными компиляторами и будет при этом работать как надо -- это был высший пилотаж программирования на C). Потому что есть стандарты и не только на компиляторы, но и на libc и на многое другое. Потому что есть pkg-config, который легко можно использовать непосредственно из makefile'а, проверяя наличие библиотек и их версии. Потому, что есть github, где очень легко отправлять pull-реквесты, получать их, создавать issues, обсуждать их, и находить решения: сегодня если софтина не собирается на какой-то особо хитрой конфигурации, то этим проблемам несложно найти решение и без autotools. Тем более, что autotools не решает этих проблем: configure в лучшем случае, поможет диагностировать эти проблемы. Потому, наконец, что сегодня из сорцов собирают только те, кому это интересно и кто готов разбираться в чём проблема, а не любой пользователь *nix, и просто потому, что других способов поставить софт не существует. А тем, кому интересно собирать софт из сорцов, совсем не обязательно иметь configure для того, чтобы делать сообщения об ошибках более информативными.

Если комментаторы опеннета в большинстве своём и выступают против замены autotools на что-то ещё, то это их "старпёрский bias" -- опеннетовское когнитивное искажение, вызванное тем, что каждому опеннетовцу хочется выглядеть старпёром, а лучший способ выглядеть старпёром -- всегда выступать в пользу музейного софта и всегда против всего нового.

Ответить | Правка | Наверх | Cообщить модератору

165. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"  +/
Сообщение от Mihail Zenkov (ok), 26-Окт-17, 10:34 
>> У меня своя система сборки. На все правки, включая написание программ для
>> сборки и обработки config.cache ушло 3-4 часа.
> Поддержание своей системы сборки будет требовать гораздо больше времени.

На самом деле - не факт. Все зависит от задач. Если вы постоянно (ежедневно) меняете набор приложений - то да, лучше использовать готовый дистрибутив. Если набор приложений относительно стабилен - то затраты по времени не большие.

Вы хорошо озвучили проблемы gentoo:

1. Глубокая модификация требует больших затрат по времени.
40-80 часов для задачи, которая в моем случае отняла 3-4 часа (да и то, если бы я сам не писал программы для этой задачи, то правки/тест сборочной системы отняли бы менее 30 минут).

У меня в год на систему уходит 40-80 часов, да и то, только если я провожу эксперименты вроде обсуждаемого.

2. Поддержка своих изменений. Чем их больше, тем сложнее поддерживать. В итоге от них приходится отказываться.

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

> Если мы попытаемся этот config.site впилить, например, в emerge и дополнить этим
> костылём с рестартом сборки, то встанет вопрос: как мы можем выяснить
> программно, что сборка обломалась из-за косяков с config.site? Или после каждого
> облома мы на всякий случай будем удалять config.site и делать рестарт
> -- а вдруг прокатит?

Как вариант. Можно еще научить систему составлять список таких случаев и сохранять логи неудачной и удачной сборки (или сразу делать с них diff) для быстрого разбора проблемы.

> Потому что есть pkg-config, который легко
> можно использовать непосредственно из makefile'а, проверяя наличие библиотек и их версии.

Совершенно верно!

> Если комментаторы опеннета в большинстве своём и выступают против замены autotools на
> что-то ещё, то это их "старпёрский bias" -- опеннетовское когнитивное искажение,
> вызванное тем, что каждому опеннетовцу хочется выглядеть старпёром, а лучший способ
> выглядеть старпёром -- всегда выступать в пользу музейного софта и всегда
> против всего нового.

Тут не соглашусь. autotools давно пора выкинуть, но:

1. Зачем писать новые системы сборки, когда для 95% проектов достаточно make + pkg-config? Зачем генерировать майкфайлы, неужели нельзя сделать их статичными, а все переменные собрать в одном файле?

2. Если уж хочется написать новую систему сборки, зачем делать хуже, чем было? Один синтаксис управления cmake чего стоит: -DCMAKE_INSTALL_PREFIX=/usr против --prefix=/usr.

3. Если проект большой - сделайте свою компактную систему сборки и встройте ее в проект, типа как в AOSP, а не заставляйте тянуть и собирать кучу зависимостей.

Ответить | Правка | Наверх | Cообщить модератору

151. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"  +/
Сообщение от Аноним (-), 25-Окт-17, 12:04 
> Весь этот вывод configure уже заучен наизусть, я его сам могу на клавиатуре набрать с закрытыми глазами, ан нет, автотулзы продолжают долбить в одну и ту же точку.

Во-первых, у configure есть кеш, см. (./configure --help); во-вторых, даже если автор не предусмотрел (--enable-foo/--with-bar), любую закорюку/переменную можно переопределить в командной строке, так что configure будет думать, что проверка сделана и результат взят из кэша. Например, моэно убедить configure, что заголовок sys/wtf.h существует, и т. д.

Такие дела :)

Ответить | Правка | К родителю #132 | Наверх | Cообщить модератору

161. "Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4"  +/
Сообщение от Orduemail (ok), 25-Окт-17, 20:14 
>> Весь этот вывод configure уже заучен наизусть, я его сам могу на клавиатуре набрать с закрытыми глазами, ан нет, автотулзы продолжают долбить в одну и ту же точку.
> Во-первых, у configure есть кеш, см. (./configure --help); во-вторых, даже если автор
> не предусмотрел (--enable-foo/--with-bar), любую закорюку/переменную можно переопределить
> в командной строке, так что configure будет думать, что проверка сделана
> и результат взят из кэша. Например, моэно убедить configure, что заголовок
> sys/wtf.h существует, и т. д.

Если я вожусь с командной строкой, то тормоза вносимые моими кривыми пальчиками и процессом мышления гораздо выше, чем тормоза ./configure. Это значит, что я только что сделал wget, потом tar jxf, вот сейчас делаю ./configure, потом буду делать make, потом искать способа потестировать работает ли без установки, потом решать, что делать с результатом -- вкатать в /usr/local при помощи make install, поставить в ~/local, поставить при помощи INSTALL_ROOT в /tmp, а потом вспоминать, читая man'ы и сорцы, как теперь всё это ebuild'ом раскатать в /usr, чтобы потом можно было бы удалить при помощи emerge... Короче эта история надолго. И в этой истории пара-тройка выполнений ./configure, пока я собираю все опции для него, которые я хотел бы ему передать, -- это вообще ни о чём.


Ответить | Правка | Наверх | Cообщить модератору

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

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




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

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