Сборка devel/llvm*

Victor Sudakov написал(а) к All в Jul 17 16:58:26 по местному времени:

Dear All,

Сабж в poudriere длится часами. Очень раздражает. Не знает ли кто, зачем это и можно ли если не избавиться, то ускорить процесс?

OPTIONS_UNSET=LLDB в make.conf уже стоит. Чего бы еще поотключать?

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

Alex Korchmar написал(а) к Victor Sudakov в Jul 17 13:32:33 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Victor Sudakov <Victor.Sudakov@f49.n5005.z2.fidonet.org> wrote:

VS> Сабж в poudriere длится часами. Очень раздражает. Не знает ли кто, зачем это и
VS> можно ли если не избавиться, то ускорить процесс?
rm, и посмотреть, кто его притащил

VS> OPTIONS_UNSET=LLDB в make.conf уже стоит. Чего бы еще поотключать?
причем тут? В devel лежит более новая версия, чем в базе. Она нахер никому не
нужна. Кто-то, вернее всего, в очередной раз тупо вбил первые попавшиеся цифири
в зависимости.

Если не удастся обмануть - попробуй вместо llvm собирать gcc поновее - он,
хотя бы, собирается несколько десятков минут, а не часов.


> Alex

--- ifmail v.2.15dev5.4

Victor Sudakov написал(а) к Alex Korchmar в Jul 17 20:00:26 по местному времени:

Dear Alex,

24 Jul 17 13:32, you wrote to me:

VS>> Сабж в poudriere длится часами. Очень раздражает. Не знает ли кто,
VS>> зачем это и можно ли если не избавиться, то ускорить процесс?
AK> rm, и посмотреть, кто его притащил

rm это как-то жестко. В Web интерфейсе poudriere видно, что devel/llvm40 собирается ради firefox, а llvm38 ради lang/clang38.

А clang38 ради security/masscan (вот этот последний я выкину из списка, так и не нашел ему практического применения, думал что будет поудобнее fping/nmap, ан нет).

VS>> OPTIONS_UNSET=LLDB в make.conf уже стоит. Чего бы еще поотключать?
AK> причем тут? В devel лежит более новая версия, чем в базе.

Э? В devel лежат просто инструменты разработки, которых в базе может вообще не быть.

AK> Она нахер
AK> никому не нужна. Кто-то, вернее всего, в очередной раз тупо вбил
AK> первые попавшиеся цифири в зависимости.

AK> Если не удастся обмануть - попробуй вместо llvm собирать gcc поновее -
AK> он, хотя бы, собирается несколько десятков минут, а не часов.

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


Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

Alex Korchmar написал(а) к Victor Sudakov в Jul 17 17:18:18 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Victor Sudakov <Victor.Sudakov@f49.n5005.z2.fidonet.org> wrote:

VS> rm это как-то жестко. В Web интерфейсе poudriere видно, что devel/llvm40
VS> собирается ради firefox, а llvm38 ради lang/clang38.
VS> А clang38 ради security/masscan
я совершенно уверен, что это рукожопость портособирателей.
firefox прекрасненько собирается gcc 4.7.2 (если оторвать внутри проверку, но
тебе такой старый и не надо), который сам собирается за несколько десятков
минут даже на не особо хорошей системе.

VS> (вот этот последний я выкину из списка, так и
выкинь ему из списка зависимостей clang

VS> У меня на попытки хакать порты нет ни времени, ни особого желания. Штатной
VS> опцией что-то отключить для ускорения сборки - другое дело, это я готов.
я подозреваю, что штатных опций от дибилоидов, пихающих зависимость от
огромного тяжелособираемого пакета, не проверив, нужна ли она вообще,
ожидать не приходится. Но ты можешь попробовать поиграть с defaults, если
заняться нечем.
Мне было бы лень даже выяснять, как эти дефолты называются.


> Alex

--- ifmail v.2.15dev5.4

Valentin Nechayev написал(а) к Victor Sudakov в Aug 17 16:34:44 по местному времени:

From: Valentin Nechayev <netch@segfault.kiev.ua>


>>> Victor Sudakov wrote:

VS> Сабж в poudriere длится часами. Очень раздражает. Не знает ли кто, зачем это и
VS> можно ли если не избавиться, то ускорить процесс?

А нельзя ли явно его собрать, чтобы FF пользовался готовым?
llvm меняется немного реже :)


--netch--
--- ifmail v.2.15dev5.4

Victor Sudakov написал(а) к Valentin Nechayev в Aug 17 09:04:24 по местному времени:

Dear Valentin,

03 Aug 17 16:34, you wrote to me:

VS>> Сабж в poudriere длится часами. Очень раздражает. Не знает ли кто,
VS>> зачем это и можно ли если не избавиться, то ускорить процесс?

VN> А нельзя ли явно его собрать, чтобы FF пользовался готовым?
VN> llvm меняется немного реже :)

Оно в poudriere так и есть. Если llvm уже собран и лежит в репозитории, он пересобираться не будет, в сборочный jail будет установлен готовый llvm и прочие зависимости из пакетов.

Но есть но: если например сборочный jail обновился из-за freebsd-update, то будут пересобраны все пакеты в соответствующем репозитории. Часто также из-за какого-нибудь automake-1.15.12 -> automake-1.15.13 по зависимостям пересобирается туча всего.

Думаю это уже родовое проклятье фревой системы портов/пакетов. В линуксах не так?

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

Alex Korchmar написал(а) к Victor Sudakov в Aug 17 15:49:51 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Victor Sudakov <Victor.Sudakov@f49.n5005.z2.fidonet.org> wrote:

VS> Думаю это уже родовое проклятье фревой системы портов/пакетов.
VS> В линуксах не так?
в линуксах не принято запускать automake и требовать зависимости от него,
если в пакете изначально есть созданный автором configure.
Этот маразм "патамушта могу!" специальный именно для фри. Я обычно удаляю
подобные зависимости до запуска make.

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


> Alex


--- ifmail v.2.15dev5.4

Victor Sudakov написал(а) к Alex Korchmar в Aug 17 09:36:42 по местному времени:

Dear Alex,

04 Aug 17 15:49, you wrote to me:

VS>> Думаю это уже родовое проклятье фревой системы портов/пакетов.
VS>> В линуксах не так?
AK> в линуксах не принято запускать automake и требовать зависимости от
AK> него, если в пакете изначально есть созданный автором configure. Этот
AK> маразм "патамушта могу!" специальный именно для фри. Я обычно
AK> удаляю подобные зависимости до запуска make.

Обновления портов/пакетов у тебя потом не ломаются из-за ручного вмешательства? Если при каждом обновлении заниматься подобным ручным вмешательством - глаза покраснеют.

AK> Не говоря уже о том, что в рамках одной версии дистрибутива не принято
AK> менять версии никаких пакетов - вообще. Если устраняются ошибки - они
AK> устраняются путем бэкпорта в ту версию, которая была в дистрибутиве,
AK> и только так.

В эхотаге в базовой системе, как я понимаю, действует та же философия в пределах релиза.

А с портами поступили как со сторонним софтом, возможно потому что это гораздо менее трудозатратно. В страшном сне представляю себе FreeBSD Core Team, бэкпортящую исправления в nginx или gnome3 потому, что на момент выхода всех поддерживаемых релизов эхотага зафиксировались такие-то их версии. Точно так же с трудом представляю себе Microsoft, фиксящий сторонний виндософт самостоятельно вместо того, чтобы предложить обновиться до последней версии, поддерживаемой вендором, даже если ради этого этом бедному пользователю придется установить 5 разных дотнетов и рантаймов.

А в линуксах, с другой стороны, я встречал немало недовольных окаменелостью софта, и подключающих разные неофициальные и неподдерживаемые репозитории со свежатиной.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

Valentin Nechayev написал(а) к Victor Sudakov в Aug 17 12:48:10 по местному времени:

Нi,

>>>> Victor Sudakov wrote:

VN>> А нельзя ли явно его собрать, чтобы FF пользовался готовым?
VN>> llvm меняется немного реже :)
VS> Оно в poudriere так и есть. Если llvm уже собран и лежит в
VS> репозитории, он пересобираться не будет, в сборочный jail будет
VS> установлен готовый llvm и прочие зависимости из пакетов.

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

VS> Но есть но: если например сборочный jail обновился из-за
VS> freebsd-update, то будут пересобраны все пакеты в соответствующем
VS> репозитории. Часто также из-за какого-нибудь automake-1.15.1_2 ->
VS> automake-1.15.1_3 по зависимостям пересобирается туча всего.

VS> Думаю это уже родовое проклятье фревой системы портов/пакетов. В
VS> линуксах не так?

В тех, что я видел, точно так же. Мелкая правка gcc поднимает пересборку чуть более, чем всего. Это считается неизбежной ценой.


-netch-

... Спамы, куки...

---

Alex Korchmar написал(а) к Victor Sudakov в Aug 17 12:51:54 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Victor Sudakov <Victor.Sudakov@f49.n5005.z2.fidonet.org> wrote:

AK>> в линуксах не принято запускать automake и требовать зависимости от
AK>> него, если в пакете изначально есть созданный автором configure. Этот
AK>> маразм "патамушта могу!" специальный именно для фри. Я обычно
AK>> удаляю подобные зависимости до запуска make.

VS> Обновления портов/пакетов у тебя потом не ломаются из-за ручного
VS> вмешательства?
из-за ручного вмешательства - нет, не ломаются. Может сломаться
из-за того, что автор порта еще чего-то нахреначил в DEPENDS, и
лучше бы это заметить, потому что очень маловероятно что там что-то
полезное, скорее всего оно - вредное.

VS> Если при каждом обновлении заниматься подобным ручным вмешательством
VS> - глаза покраснеют.
сказал человек, собравший аж целую систему сборки сборок...

VS> В эхотаге в базовой системе, как я понимаю, действует та же философия в
VS> пределах релиза.
в эхотаге в базовой системе пакеты появились без году неделя, и как
они работают я лично даже не хочу узнавать.

VS> менее трудозатратно. В страшном сне представляю себе FreeBSD Core Team,
VS> бэкпортящую исправления в nginx или gnome3 потому, что на момент выхода
VS> всех поддерживаемых релизов эхотага зафиксировались такие-то их версии.
совершенно все равно что там где "зафиксировалось". А вот возможность
поставить за месяц десяток систем, и быть уверенным, что версия nginx
в них одна и та же - чего с freebsd никогда не будет - это как раз хорошо.
А самая наираспоследняя как раз нужна редко, обычно это один-единственный
пакет на всю систему, чаще всего либо тот, ради которого она вообще стоит,
либо одна из его ключевых зависимостей. И это, внезапно, может быть и вовсе
не nginx, который ради какой-нибудь админки, используемой раз в тыщу лет.

VS> с трудом представляю себе Microsoft, фиксящий сторонний виндософт
microsoft прекрасненько это делает, в рамках поддерживаемых версий.
Более того, сейчас и отказаться-то от апдейтов какого-нибудь офиса
одновременных с апдейтами базовой системы крайне непросто.

VS> А в линуксах, с другой стороны, я встречал немало недовольных
VS> окаменелостью софта, и подключающих разные неофициальные и
это пыонэры, не надо их недовольство вообще слушать.
основная проблема линуксов - короткий жизненный цикл в 100% бесплатных
и почти всех - платных (очень подорого нынче платных) дистрибутивах.
Причем даже там, где якобы тебе обещают семь лет - выясняется что либо это
семь лет ничего не делания, разьве что совсем критические ошибки устраняют,
с опозданием на пол-года, либо на самом деле через год под видом апдейта
меняется весь дистрибутив, ломая и api, и abi.


> Alex

--- ifmail v.2.15dev5.4