> Это как это, опознав _некоторые_ хидеры, можно прописать _все_ зависимости?хидеров конечное количество, вообще-то. и совершенно не нужно знать все 100500, кстати. а режим «для особо ленивых» позволяет выцепить из хидеров функции, поискать их в so-шках, потом прошерстить pkg-config на предмет этих исошек и обновить базу известных хидеров. автоматически. что забавно — это вполне себе удовлетворительно работает, не так часто приходится руками мозги вправлять. плюс оно умеет отлавливать ошибки линковки и делать то же самое (почти) с ними. это если хидеры системных библиотек.
хидеры же самого софта — простейший разбор include, иногда «почти-грепы» на предмет вызова чего-то откуда-то.
в итоге порождаются вполне удобоваримые скрипты сборки, притом человекочитаемые и даже с комментариями, зачем оно притащило ту или иную фичу. моё участие обычно заключается в том, что я пинаю генератор (на заведомо собираемой программе, натурально) и получаю в итоге необходимую сборочную конфигурацию.
некоторое усложнение разве что с опциями-дефайнами, которые надо выдёргивать из автокрапа: всё никак не соберусь допилить толковый анализатор.
> Ещё раз: формально это программа, фактически — конфиг в виде программы.
а сишный исходник — это конфиг для процессора. в виде программы. угу.
> и то, глядя на ./configure, низкого качества.
а я разве про конфигур говорил? O_O я, как раз, говорил про то, что основной причиной создания подобной штуки у меня было хроническое неприятие продуктов жизнедеятельности автокрапа. и да, это не для make, это немного для другой системы сборки (с одной стороны — попроще, с другой — помощнее и поумнее).
