Системы автоматизации сборки (make vs. autotools vs. cmake)

[eddy]

autotools в этом плане лояльны к пользователю — кроме стандартных утилит и того, что требуется непосредственно программе, ничего больше не требуется.

Точнее: кроме autotools ничего не требуется (если все необходимое уже есть).
Точно так же и с cmake: кроме cmake ничего не требуется

Этот мусор и время меньше, чем время, необходимое на то, чтобы найти и собрать лишнюю сущность по имени CMake. Ну, не нужна эта штука пользователю совершенно.

Т.е. вы не считаете, что пользователю нужно время, чтобы найти и собрать autotools?

[Bizdelnick]

Этот мусор и время меньше, чем время, необходимое на то, чтобы найти и собрать лишнюю сущность по имени CMake.

При сборке одной программы - да, а при сборке десятка? Сотни?

[watashiwa_daredeska]

Т.е. вы не считаете, что пользователю нужно время, чтобы найти и собрать autotools?

Пользователю не нужны autotools. Autotools нужны разработчику, чтобы сгенерить скрипт configure. А пользователь пользуется уже готовым configure, которому не нужно ничего лишнего.

При сборке одной программы - да, а при сборке десятка? Сотни?

Если я собираю десятки и сотни программ, то это уже нетипичный случай. Что-то вроде "профессиональный сборщик". Тут уже можно ориентироваться, конечно, почти как на разработчика.

[Bizdelnick]

Если я собираю десятки и сотни программ, то это уже нетипичный случай. Что-то вроде "профессиональный сборщик". Тут уже можно ориентироваться, конечно, почти как на разработчика.

Или гентушник. :-) А в бинарных дистрах собирают программы как раз профессиональные сборщики. Сборка отдельно взятой программы - вообще довольно нетипичный случай.

[watashiwa_daredeska]

Или гентушник. :-)

Гентушнику так же пофиг, чем собирается программа, как и мне в Debian. Точнее, в генту все программы собираются emerge'м. Так что, это не тот случай.

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

Скажем так, более-менее живых используемых дистрибутивов пусть десятки, может сотни. А людей, собирающих отдельные программы самостоятельно, при всей их нетипичности — тысячи. Так что, сборка программы не "профессиональным сборщиком", думаю, более типична, чем сборка хорошо подготовленным сопровождающим пакета.

[kamre]

Этот мусор и время меньше, чем время, необходимое на то, чтобы найти и собрать лишнюю сущность по имени CMake. Ну, не нужна эта штука пользователю совершенно.

gcc, gnumake и dev пакеты библиотек значит нужны для сборки, а CMake прям сразу лишняя сущность ) С таким же успехом можно заявить, что gnumake лишняя сущность, т.к. всю сборку можно сделать через shell скрипты.

[watashiwa_daredeska]

gcc, gnumake и dev пакеты библиотек значит нужны для сборки

gcc и dev-пакеты нужны программе, а не системе сборки. Кроме того, autotools рассчитаны на то, что и gcc не обязателен — autotools умеют находить множество разных C compiler'ов, включая POSIX-стандартный cc на крайний случай. gnumake для autotools не обязателен, достаточно любого стандартного make.

всю сборку можно сделать через shell скрипты.

make — такой же стандартный компонент POSIX-системы, как и shell. Это значит, что откуда-то тянуть и собирать его не нужно, make в системе должен быть готовый, если это POSIX-система, а не винда.

[eddy]

Autotools нужны разработчику, чтобы сгенерить скрипт configure. А пользователь пользуется уже готовым configure, которому не нужно ничего лишнего.

Тьфу, sorry, забыл (я-то и пользователь, и разработчик в одном лице ).

С таким же успехом можно заявить, что gnumake лишняя сущность, т.к. всю сборку можно сделать через shell скрипты.

Или вообще сразу бинарный пакет ставить

gcc и dev-пакеты нужны программе, а не системе сборки.

А вот и нет: программе нужны библиотеки, а системе сборки - dev-пакеты (заголовочные файлы, статические - в случае необходимости - библиотеки и т.п.).

make в системе должен быть готовый, если это POSIX-система, а не винда.

Его может и не быть, если вы его не установите. Например, в мандриве все эти gcc, make и dev-библиотеки по умолчанию не устанавливаются, пока вы не выберете "разработку".

[watashiwa_daredeska]

А вот и нет: программе нужны библиотеки, а системе сборки - dev-пакеты (заголовочные файлы, статические - в случае необходимости - библиотеки и т.п.).

Тут опять надо разделить и рассмотреть два случая:
1. Расчет делается на мега-систему, вроде Debian или Gentoo, где всё уже есть. Тогда, конечно, и cmake — не проблема, ибо его искать и собирать не надо, есть готовый в репах.
2. Расчет делается на минимизацию усилий по установке в произвольной обстановке. Тогда и cmake надо собирать самостоятельно, и библиотеки, но… в этом случае не будет никаких dev-пакетов, ибо это уже дистрибутивные примочки. Т.е. никаких лишних телодвижений по установке каких-то дополнительных (не нужных самой программе) компонентов от библиотек не исходит.

Его может и не быть, если вы его не установите.

Установку стандартного компонента системы можно считать простой и быстрой задачей, не стоящей внимания. На то он и стандартный компонент.

P.S. Кроме того, хорошо, когда программа умеет при сборке мягко снижать объем функций в случае недоступности некоторых библиотек, а не фэйлить, если хотя бы одной из 100500 библиотек нет. В этом случае, пользователю легче получить хоть как-то работающую программу, а потом уж итеративно допиливать.

[Nazyvaemykh]

всю сборку можно сделать через shell скрипты.

make — такой же стандартный компонент POSIX-системы, как и shell. Это значит, что откуда-то тянуть и собирать его не нужно, make в системе должен быть готовый, если это POSIX-система, а не винда.

Точно? Разве не нужны именно GNU make и GNU m4? Разве autotools работают в системах, отличных от GNU?

[watashiwa_daredeska]

Точно? Разве не нужны именно GNU make и GNU m4? Разве autotools работают в системах, отличных от GNU?

Сами autotools — не знаю, не пробовал, но полученный configure отлично работает в не-GNU.

[Bizdelnick]

в генту все программы собираются emerge'м. Так что, это не тот случай.

И как это влияет на время сборки?

[eddy]

P.S. Кроме того, хорошо, когда программа умеет при сборке мягко снижать объем функций в случае недоступности некоторых библиотек, а не фэйлить, если хотя бы одной из 100500 библиотек нет. В этом случае, пользователю легче получить хоть как-то работающую программу, а потом уж итеративно допиливать.

Полностью с этим согласен. Поэтому и делаю так: если какой-то некритичный компонент недоступен, просто не будет части функционала (а при попытке доступа к ней выдается сообщение с просьбой установить недостающую библиотеку и пересобрать проект).

И как это влияет на время сборки?

Насколько я помню, в дженте configure-скрипты при установке тоже запускаются. И на них тратится неплохая часть времени.

[watashiwa_daredeska]

в дженте configure-скрипты при установке тоже запускаются. И на них тратится неплохая часть времени.

Я не знаю, как там делается в генте, но configure умеет кэшировать результаты. По-моему, можно даже что-то вроде system-wide кэша ответов на типовые тесты делать, тогда они будут моментально отрабатывать. Точно не помню, давно это было.

Ага, вот:

The site initialization script can specify a site-wide cache file to use, instead of the usual per-program cache. In this case, the cache file gradually accumulates information whenever someone runs a new configure script.

http://www.gnu.org/s/hello/manual/autoconf/Cache-Files.html

[deadhead]

Я не знаю, как там делается в генте, но configure умеет кэшировать результаты. По-моему, можно даже что-то вроде system-wide кэша ответов на типовые тесты делать, тогда они будут моментально отрабатывать. Точно не помню, давно это было.

AFAIK, не менее давно эта фитча была бесследно удалена из пакетного менеджера генты...

[Stauffenberg]

Я, как человек несведущий в этом деле, хотел бы, чтобы человек, более знакомый с cmake, уточнил мои данные про поддержку платформ, в первую очередь - bsd (:

Во FreeBSD работает отлично