> Что-то мне подсказывает, что второго таки больше.Тут есть некий catch: на диагностику проблем в ручном режиме и потом отсыл этих некрофилов в пешее - потратится время живого человека. А не процессора.
> Тоже мне проблема, доставил либу и дальше себе make,
А зачем cmake тогда занимает место у меня на винте? А если совсем уж хардкорить - так я в принципе и без make file-ов даже обойтись могу. Поставил либы да покомандовал компилером вручную. Неудобно, но работать будет. Вон там автор какой-то проги для тестирования LCDшника - ушибся в край и затребовал scons. Вся прога - 1 тривиальный файл, чуть сложнее hello world. Я почесал репу, проверил наличие libsdl-ных хидеров сам и вкатал gcc команду. Он собрал. И никаких скунсов ставить не надо. Вот зачем так делать, граждане разработчики?
> ровно с того же места и продолжит.
И все это прекрасно, но вообще-то его задача была меня послать ДО начала компила, а не через 5 минут, когда я куда-то переключился...
> во флаги компилятора и линкера, из-за чего придётся пересобирать уже собранное.
Ну так я и вопрошаю: а система сборки и генерации make-файла зачем место у меня на винте занимает тогда?
> Думаю, таки не толпа, а полтора мейнтейнера, которым первыми посчастливилось с этим
> столкнуться.
А также те кто попробовал собрать распоследнюю версию на посмотреть. При том у тех кто умеет софт собирать - порой бывают странноватые системы. Какие-нибудь бояздэшники в два счета притащатся с своим окаменелым gcc 4.2, или какой-нибудь старый извращенец с какой-нибудь соляркой попадется. Мало ли.
>> для сборки и дeтeктирования ключевых параметров системы.
> Позвольте полюбопытствовать из общего интереса: а вы их зачем сами столько собираете?
С самыми разными целями:
1) Иногда программы может не быть в репах.
2) Или она может быть не той версии. Или опции сборки не по вкусу. Или что там еще.
3) Иногда может захотеться получить программу версии не менее чем эн, с вон той фичой, прямо сейчас, а не когда раздуплятся майнтайнеры. Или напротив - сделать реверт на версию где не было ужасно донимающего бага. Случаи бывают разные.
4) Иногда бывает так что хочется посмотреть на будущее уже сейчас. Возможно вкатав багов до того как проблемный багодром разлетится по дистрам и будет годами иметь мозг юзерью, в том числе и мне.
5) Иногда бывает так что программа ну всем хороша. Но вот эта мелочь - анноит. Или ну самую капельку чего-то не хватает. Можно, блин, пойти и самому это пропатчить. На то оно и опенсорс.
6) А иногда проект и народ в нем может понравиться настолько, что с ними просто нравится работать. При этом я могу и немного коммитов зафигарить. Не то чтобы я великий програмер, но в современном мире как-то очень уж сложно жить, если программить не умеешь. И уж разумеется до этого придется проверить как это компилится.
> Кстати, к слову о каждой сборке, просто из интереса: автотулз может рассчитывать
> зависимости между файлами
Как таковой некий трекинг зависимостей там есть...
> и для чего надо (как AUTOMOC в cmake), пересобирать только нужные
> .cpp, когда поменялся хедер?
...но в такие дебри я не лазил.
> Вот сколько лет на генте сижу, ничего не разваливалось.
Тут наверное еще от прямизны рук и везения зависит. А отдельные маньяки генту на нью-йоркской бирже гоняют, так что в умелых руках и гента - стабильна, иначе бы им финансисты давно что-нибудь открутили. Но такие приколы - имели место быть. И в среднем по больнице редкий псих рискнет вкатить генту на что-то продакшновое...
> Так либы детектируются не так, или cmake неправильно ругается, когда отсутствие
> сдетектировалось таки как надо?
Чаще всего - детектируется не так. В смысле, cmake и проц. считает что все ЗБС но в результае оказывается не ЗБС и сборка заваливается на середине. Я даже допускаю что у одного конкретного deadfood cmake работает отлично. Но вот большинство авторов софта почему-то не могут нормально детектировать все либы cmake.
С точки зрения сборки программы это означает что "если программа использует cmake, придется попрыгать по граблям". Поэтому при прочих равных я программу с автокрапом буду собирать - он если завалится то по крайней мере пишет почему. Накрайняк лог есть, где он пишет что делалось. А у cmake сообщения обычно невнятные, часто случается "все ЗБС, но сборка свалилась", а если проверка не прошла - диагностика далеко не всегда очевидна и надо чуть ли не клещами выдергивать недостающее инфо.
> Красивый прогресс — это хорошо, конечно, но мне как-то важнее, чтобы оно
> быстрее собиралось. Недостаток весьма минорный, ИМХО.
Ну да. Просто фича из разряда "не умеешь - не берись". Хотели как лучше, с гламурным прогрессом. А в реальности получилось как всегда - многопоточный хаотичный гадеж в консоль мусором. ИМХО лучше бы там без по дефолту рисовался просто вывод компилера: спам примерно одинаково нечитабельный, зато если факап случился - ну хоть диагностика сразу под рукой.
> Кстати, в cmake с таким не встречался. Про билдсистему того софта, где
> встречался, впрочем, не помню, были ли это автотулзы или что ещё.
А мне такое попадалось почему-то в основном для софтин с cmake. Хотя, разумеется, проблема потенциально вылезти быть где угодно.
> А при однопоточной при этом всё нормально, не заваливается ничего? Во дела.
> Прям аж тоже стало любопытно.
Ну я так понимаю что случаются какие-то гонки. Это наверное не только для cmake характерно, но мне попадалось именно в прогрмамах с ним. Т.к. я не собирал статистику по таким приколам - я не буду настаивать что это эксклюзивная "фича" cmake и тех кто его использует :)
> Как-то всё-таки не факт.
Ну не знаю, мой опыт какой-то вот такой. При том программы с автотулсами были большинством и при более-менее равной проблематичности стало быть и проблем у меня должно было бы быть больше всего именно с автотулсами. А на практике - автотулсы конечно ужасны по внутренностям. Но этот жуткий пи...ц каким-то чудом работает и даже обычно не создает лишних проблем. Хоть я и могу понять антипатии к этому килограмму скриптокостылей, в которые страшно соваться.
