ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Понедельник
22 июля
1058852 Топик полностью
fk0, легенда (08.12.2020 22:16, просмотров: 501) ответил RxTx на Всё дело в поддержке. Очень сложно поддерживать сборку на десяток платформ с разными компиляторами с разными либами когда всё это жестко прописано до файла. Наступает а) комбинаторный взрыв и б) учёт каждого файла вручную для каждой конфигурации. Cmake аналог configure scripts на самом деле. P.S. тебе как красноглазику, лишь бы доебаться с вопросом что лучше/хуже, приступиться и трясти за грудки. Заметь, я ни разу не сказал лучше/хуже. Не холиварь =)
А CMake по-твоему волшебный и там ничего не возникает? Если исключить веру в волшебную программу которая делает всё (а она понятия не имеет как делать всё) то CMake по сути -- ПУСТАЯ АБСТРАКЦИЯ. Она имеет смысл для тех случаев, когда работают её встроенные правила, но когда их нет -- обычный Make ничем не хуже. Я не доебаться, просто вижу, что пропагандируются какие-то взгляды, мол XXX -- волшебное и единственный true way, а всё остальное мол говно. Вопрос почему и какими 

свойствами оно обладает не задаётся -- ведь "все используют Cmake..." Критическое мышление отсутствует напрочь, одна вера в авторитеты. Стадный эффект.


Если говорить о комбинаторном взрыве, лично я думаю, что система вроде biomake доведённая до ума была бы лучше: где базовые возможности make дополняются декларативным ЯВУ -- Прологом. Комбинаторного взрыва не будет, по крайней мере в голове у программиста и в тексте програмы (оно переместится куда-то в дебри рантайма, который сам будет решать задачки), если не пытаться все задачи решать в императивном стиле. Данную задачу вполне можно переложить на компьютер, если объяснить ему правила решения задач (декларативный стиль), а не пытаться заранее самостоятельно в голове перебрать все варианты и тупо в лоб закодировать (императивный). Не обязательно пролог, не обязательно make, важна лишь сама идея: нужен набор правил, применяя которые можно задачу решить. А не конкретное решение задачи для конкретного случая. В принципе make декларативный, но только лишь по отношению к зависимостям файлов (верней "целей"). Но как язык программирования он явно плох (не просто так его пытались расширять с помощью guile (scheme). Вообще декларативная часть не обязана быть специальным языком программирования, а может быть подмножеством реализованном в любом языке (хоть в питоне). Ключевой момент -- что она должна быть, она принципиально необходима. Не как способ определить, что файл x.o нужно пересобрать, если x.c новей. А как средство автоматического решения задач (программист полного решения не знает).


Вообще на мой взгляд при создании новых инструментов важно выбрать правильно язык. Нет смысла изобретать свой самодельный (как сделали авторы CMake), кривой, косой, с массой взаимоисключающих правил и несовместимостью между версиями. Можно взять любой удобный уже существующий язык (тот же python, tcl, что угодно, даже scheme). Что сильно упростит жизнь пользователям, т.к. какие-то элементарные действия перестанут быть камнем преткновения (вроде добавления строки в список в версии CMake ниже такой-то). И средствами языка уже реализовать подмножество пригодное для решения конкретной прикладной задачи (DSL). И ту же систему декларативного программирования -- как отдельное подмножество языка. В своё время сильно плевался на конфиги sendmail (https://web.mit.edu/~simsong/www/ugh.pdf -- см. стр. 101 в pdf или 61 в бумаге) но теперь понимаю, это решение на голову выше, чем, например, postfix...

[ZX]