> Зато у некрофагов с этим древним юниксом (извращенцев хватает) - оно запустится.
> И может их послать в пешее эротическое, рассказав какое гэ их
> система. И они будут тихонько чинить свой крап под соответствие актуальному
> состянию дел, или пойдут лесом. И это лучше чем если эти
> некрофаги припрутся к автору программы и будут канифолить мозг.Интересно было бы замерить, сколько ресурсов CPU разработчиков было потрачено зря на общение с некрофилами, а сколько — на ожидание завершения всех этих проверок. Что-то мне подсказывает, что второго таки больше.
> А с
> каким-нибудь cmake обычно получается так что детектирование всего и вся вроде
> бы проходит успешно, все ЗБС, но на 69% компиляции, через 5
> минут прогрева проца, когда юзерь уже пускает слюни на почти готовый
> бинраь, все вдруг ВНЕЗАПНО заваливается, наконец.
Тоже мне проблема, доставил либу и дальше себе make, ровно с того же места и продолжит. Если либа не ставится куда-нибудь в странное место, конечно же, что потребует дописывания всяких -I, -L и -l во флаги компилятора и линкера, из-за чего придётся пересобирать уже собранное.
> А вот в этом месте
> толпа народа прется к авторам программы и злостно греет мозг.
Думаю, таки не толпа, а полтора мейнтейнера, которым первыми посчастливилось с этим столкнуться.
> Поэтому как ни странно, по опыту сборки туевой хучи программ, автотулсы в
> среднем по больнице - наиболее безграбельны как именно инструмент проверки зависимостей
> для сборки и дeтeктирования ключевых параметров системы.
Позвольте полюбопытствовать из общего интереса: а вы их зачем сами столько собираете?
> Но запускается далеко не на каждую сборку (в плане проблемности для разработчика).
Кстати, к слову о каждой сборке, просто из интереса: автотулз может рассчитывать зависимости между файлами в проекте сам, вызывать moc сам когда надо и для чего надо (как AUTOMOC в cmake), пересобирать только нужные .cpp, когда поменялся хедер?
> Я компилил достаточно программ под разными системами, чтобы без них оценить "а
> как оно". Да и вообще, мнение гентушников у которых вообще какой-нибудь
> там развал портажей по причине "версия бидона не та" не является
> чем-то из ряда вон - для меня имеет достаточно ограниченную ценность
Вот сколько лет на генте сижу, ничего не разваливалось. И у знакомых ничего не разваливалось. И как-то все эти развалы по причине бидонов проходили мимо меня.
> Да хз, какой проект ни ткни, либы детектируются через пень колоду. Я
> даже затрудняюсь кого-то конкретного выделить - с этим не ахти было
> вообще у всех. Ну вон vcmi в свое время никак не
> мог с ffmpeg совладать. Сообщал что все ЗБС, но сборка потом
> падала где-то на середине.
Так либы детектируются не так, или cmake неправильно ругается, когда отсутствие сдетектировалось таки как надо?
> А если уж мы про многопоточность - make file от cmake выводят
> в консоль при 8 потоках полное месиво вместо красивого прогресса.
Красивый прогресс — это хорошо, конечно, но мне как-то важнее, чтобы оно быстрее собиралось. Недостаток весьма минорный, ИМХО.
> еще там часто бывают race conditions, когда в 1-поточном режиме сборка
> проходит всегда, а если в 8 потоков фигарить - сборка отлетает
> с дурной ошибкой без особых причин. И прокатывает раза со второго-третьего.
Кстати, в cmake с таким не встречался. Про билдсистему того софта, где встречался, впрочем, не помню, были ли это автотулзы или что ещё.
> Не совсем понимаю как народ добивается таких красивых гонок. Но если
> нечто билдуется cmake, оно при многопоточной сборке нередко и ВНЕЗАПНО заваливается
> в середине сборки, а вывод на консоль при этом отражается лурковским
> "кровь, кишки, распи...сило".
А при однопоточной при этом всё нормально, не заваливается ничего? Во дела. Прям аж тоже стало любопытно.
> Теоретически все вроде бы так. Практически - толи в автотулсах это проще
> делать, толи еще какие-то факторы. Но факт в том что при
> сборке программы с автотулсами ВНЕЗАПНО валятся гораздо реже.
Как-то всё-таки не факт.
