Нужен совет по выбору *make

Ничего сверх make тут на самом деле не нужно, особенно если речь идёт не просто о сборке а о костыляции со скачиванием исходников. Просто прочтите мануал по нему и напишите Makefile так, чтобы он НЕ пересобирал ВСЁ каждый раз.

cmake не аналог make. Это разные программы. И да, с помощью него ты можешь сгенерировать нужный мейкфайл

Подскажите, как с минимальным велосипедизмом реализовать разрешение зависимостей и возможность сборки выбранных вариантов? Точнее, как автоматически генерировать make файл по конфигу с описанием зависимостей?

Makefile — это и есть конфиг описания зависимостей, причем в твоем случае очень простой. Не надо ничего изобретать.

Могу ошибаться, но мне кажется, стоит использовать Buildroot или OpenEmbedded под эту цель.

Для С голова цели со всеми зависимостями (для одного модуля) генерится при помощи «gcc -M» (ваш К.О.)

Остальное по моему ручками проще задать.

cmake + ExternalProject ?

На перле: http://pastebin.com/WWbLL4r8

Конфиг conf/packages.conf вида

[prepare]
dep:
build: false

[zlib]
dep: prepare
build: false

[openssl]
dep: prepare
build: false

[curl]
dep: prepare
build: false

[gettext]
dep: prepare
build: false

В результате получим Makefile вида ( привожу только кусок файла )

#####################
# curl
#####################
curl: build_curl

build_curl: build_prepare
    if [ -f "$(script_dir)/build_curl.sh" ]; then $(script_dir)/build_curl.sh; fi
    touch build_curl

clean_curl: 
    if [ -f "$(script_dir)/clean_curl.sh" ]; then $(script_dir)/clean_curl.sh; fi
    rm build_curl 2>/dev/null ; /bin/true

[...]

Ну это я как бы знал. Задача была именно в автоматическом построении Makefile из человекочитаемого конфига, описывающего зависимости.

И вторая задача - перечисление целей для сборки, из того же конфига ( хотя сейчас подумал - наверное стоит автоматически добавлять в Makefile цели all и selected )

Всё это уже сделал, ссылка на скрипт и пример выше

cmake не аналог make. Это разные программы. И да, с помощью него ты можешь сгенерировать нужный мейкфайл

Спасибо, в следующий раз почитаю документацию к cmake. Вчера уже написал костыль.

Makefile — это и есть конфиг описания зависимостей, причем в твоем случае очень простой. Не надо ничего изобретать.

Не надо его править вручную. Когда пакетов больше сотни, править эту паутину - неблагодарное занятие.

Именно поэтому мне нужно было строить Makefile из конфига с перечислением зависимостей.

Но я уверен что такая задача вставала перед многими программистами и навернака штатно решается через какой-либо аналог make ( cmake, scons и т.д. )

ваще-то это решает обычная make. Именно так, как ты сказал — просчитывает зависимости, а потом собирает то, что нужно. Причём ещё и одновременно собирает независящие ветки. (с опцией -j).

Именно поэтому мне нужно было строить Makefile из конфига с перечислением зависимостей.

ну это только костылём. А из C/C++ кода оно делается gcc -MD, который создаёт маленькие Makefile'ы, *.d, по одному на каждый модуль. Потом они включаются в общий Makefile. В этих *.d файлах как раз и перечислены зависимости *.o файлов, т.е. какие именно *.h файлы включаются в *.c файл.

Естественно для велосипедного конфига нужен велосипедный костыль.

Не надо его править вручную. Когда пакетов больше сотни, править эту паутину - неблагодарное занятие.

Именно поэтому мне нужно было строить Makefile из конфига с перечислением зависимостей.

Какая паутина? У тебя сто пакетов. Каждый пакет - цель в Makefile. Если пакет А зависит от пакета Б, у соответствующей цели появляется соответствующая зависимость.

* Под пакетом я понимаю уже готовый проект, использующий какую-то систему сборки. Судя по первоначальному описанию, так и есть. В противном случае нужно настраивать и сборку каждого из пакетов.

Какая паутина? У тебя сто пакетов.

A зависит от B

build_a: build_b # <---
 ...
clean_a:
 ...

build_b:
 ...
clean_b: clean_a # <---

Это два пакета. А их реально больше сотни. Обрати внимание, зависимость прописывается в двух местах. Писать такой makefile вручную будет только идиот, даже если забыть про неизбежные опечатки.

clean_b: clean_a

Это не нужно. А уже собран, теперь ему насрать на Б. Ты сюда притягиваешь функцию пакетного менеджера.

UPD. Я конечно понимаю, что в Б может быть разделяемая библиотека, используемая в А, но это лишь частный случай. Зачастую А будет работать без Б.

Зато мне не плевать на то, что пакет возможно придётся пересобрать.

И тем более не плевать на то, что задачи по сборке в makefile - типовые, вызов соответствующего скрипта. И в таких условиях редактировать makefile вручную - см. выше

Что касается типовой задачи, в Makefile можно написать общее правило сборки «чего-либо», т.е. само описание целей и зависимостей остается простым-однострочным. А по первому пункту ничего не могу сказать, я ни в одной системе сборки не видел (может оно и есть) разворачивания зависимостей для очистки. Я бы в такой ситуации просто написал скрипт конвертации конфига в Makefile, ИМХО это проще и быстрее поиска готового решения.

Я бы в такой ситуации просто написал скрипт конвертации конфига в Makefile

%) Нужен совет по выбору *make (комментарий)

Я видел)

В общем, я имел в виду и так и не дописал... Не лучшим ли вариантом будет разделить процессы сборки и эксплуатации пакетов? Для сборки соответственно использовать систему сборки с одними зависимостями, а для эксплуатации — пакетный менеджер со своими зависимостями. Для обеих задач есть готовые решения. Во время сборки проекта создаешь пакет. Потом все пакеты регистрируешь в менеджере пакетов. Затем при необходимости использования утилиты в ондроеде ты устанавливаешь пакет, он разворачивает и устанавливает свои зависимости, и в конце концов скидываешь все это на свою мобилку. Юниксвей.

Задача была именно в автоматическом построении Makefile из человекочитаемого конфига, описывающего зависимости

Я повторяю: если прямыми руками писать makefile, он и будет тем самым конфигом, вида

target1: target2 target3

target2: target4 target5

target5: target6 target7

а сбоку будут лежать все правила с описанием команд.

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

Объясните по-русски этот набор слов.

Я бы с удовольствием, но учётку заблокируют за мат.

чего только не выдумают лишь бы gradle не собирать