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

[eddy]

i	Уведомление от модератора Bizdelnick
	Отрезано от Публикация и разработка программы

make — наше всё·

Это только для проекта из одного файла годится. Или если вы не собираетесь делиться кодом.

[IMB]

make — наше всё·

Это только для проекта из одного файла годится. Или если вы не собираетесь делиться кодом.

Откуда такое мнение? Не знаю как у других, но SDK от TexasInstruments использует именно make и нельзя сказать, что это проект из одного файла.
Другой пример достаточно крупного проекта использующего make - linux.

[eddy]

SDK от TexasInstruments использует именно make

Оно у них хоть работает? А то бабки они за свои поделки требуют бешеные, а как спросишь на конференции, так: то не работает, это не работает...

Вообще, конечно, я согласен: можно и в make все запихнуть, но проще ведь написать сценарий для какого-нибудь cmake, и пусть он себе автоматом все нужное ищет, подставляет пути и генерирует Makefile.

[IMB]

SDK от TexasInstruments использует именно make

Оно у них хоть работает? А то бабки они за свои поделки требуют бешеные, а как спросишь на конференции, так: то не работает, это не работает...

Если Вы про сборку Make-ом - работает.

Вообще, конечно, я согласен: можно и в make все запихнуть, но проще ведь написать сценарий для какого-нибудь cmake, и пусть он себе автоматом все нужное ищет, подставляет пути и генерирует Makefile.

Тут скорее вопрос личных предпочтений и навыка. Например, я недавно собирал библиотеку для интеграции libvlc с Qt. Система сборки написана с использованием Cmake, а у меня, как назло, Qt находится в нестандартном месте и инструкция Cmake FIND_PACKAGE(Qt4 REQUIRED) её не нашла и пришлось передать её ключём. Да, с другими системами сборки возникла бы аналогичная проблема, но при использовании make я могу легко подключить внешний файл, используя include, с указанием всех внешних зависимостей, думаю в Cmake это тоже должно быть.
Чем мне ещё не нравится Cmake - он "загрязняет" директорию своими служебными файлами/директориями.

[watashiwa_daredeska]

но проще ведь написать сценарий для какого-нибудь cmake

А еще проще, писать сценарий для какой-нибудь такой хитровыпендренной штуковины, которой вообще ни у кого нет. А posix shell'ом и make'ом пользоваться невозможно и ни в коем случае не надо — они есть у всех :)

[eddy]

инструкция Cmake FIND_PACKAGE(Qt4 REQUIRED) её не нашла

Потому что неправильно делали. Надо было через pkgconfig.

Чем мне ещё не нравится Cmake - он "загрязняет" директорию своими служебными файлами/директориями.

Зато работает намного быстрее autotools.

А posix shell'ом и make'ом пользоваться невозможно и ни в коем случае не надо — они есть у всех

Покажите мне человека, у которого нет cmake. Да приличную толику пакетов без него не собрать никак.

[watashiwa_daredeska]

Покажите мне человека, у которого нет cmake

Я.

Да приличную толику пакетов без него не собрать никак.

Во-первых, Debian Sid, ветка main: ~2.88%, достаточно много каких-то kde* пакетов. А если считать те, которыми я пользуюсь, так и вообще штучно.
Во-вторых, то, что <3% пользуются cmake, еще не повод говорить, что проверенные временем make и autotools неюзабельны. Вполне возможно, что использование cmake в этих проектах — недостаток, до исправления которого просто руки еще не дошли.
В-третьих, есть разница между лабать для себя (или для компании) нечто, чего никто никогда не увидит или увидит только в бинарном виде, и писать нечто, распространяемое в исходниках и предназначенное для компиляции кем угодно в совершенно разнообразных окружениях.

[Bizdelnick]

Пока видел только проекты, перешедшие с autotools на cmake, но не наоборот. И субъективно при сборке с cmake дело иметь приятнее: работает шустрее, бинарники складывает отдельно, а не раскидывает по всем каталогам.

[IMB]

бинарники складывает отдельно, а не раскидывает по всем каталогам.

Но Вы же понимаете, что это зависит не от системы сборки, а от её конфигурирования?

P.S. Так как затронутая тема достаточно обширна, предлагаю не засорять основной топик, а перенести обсуждение в другое место.

[Bizdelnick]

Но Вы же понимаете, что это зависит не от системы сборки, а от её конфигурирования?

Понимаю, хотя в случае с autotools - не уверен, что такое возможно.

[eddy]

Я.
Во-первых, Debian

Вот. У Debian один из самых больших репозиториев. А вам, скорее всего, просто не приходилось пользоваться чем-то, чего там нет.

Во-вторых, то, что <3% пользуются cmake, еще не повод говорить, что проверенные временем make и autotools неюзабельны.

А я так не говорю. Я просто говорю, что с cmake собирать намного проще, чем вручную писать длиннющие Makefile'ы или использовать медлительные autotools.

В-третьих, есть разница между лабать для себя (или для компании) нечто, чего никто никогда не увидит или увидит только в бинарном виде, и писать нечто, распространяемое в исходниках и предназначенное для компиляции кем угодно в совершенно разнообразных окружениях.

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

Вы сами попробуйте. Я поначалу тоже считал, что кроме make'а ничего не нужно. Потом попробовал autotools, а когда наткнулся на проблему с нахождением autoconf'ом библиотек CUDA, перешел на cmake. Им и пользуюсь.

[Bluetooth]

Покажите мне человека, у которого нет cmake

Я.

Да приличную толику пакетов без него не собрать никак.

Во-первых, Debian Sid, ветка main: ~2.88%, достаточно много каких-то kde* пакетов. А если считать те, которыми я пользуюсь, так и вообще штучно.
Во-вторых, то, что <3% пользуются cmake, еще не повод говорить, что проверенные временем make и autotools неюзабельны. Вполне возможно, что использование cmake в этих проектах — недостаток, до исправления которого просто руки еще не дошли.
В-третьих, есть разница между лабать для себя (или для компании) нечто, чего никто никогда не увидит или увидит только в бинарном виде, и писать нечто, распространяемое в исходниках и предназначенное для компиляции кем угодно в совершенно разнообразных окружениях.

3% - уже серьезно. Если учесть, что некоторые проекты переходят с autotools на cmake, то, возможно, это имеет смысл, что означает, что со временем доля проектов с cmake возрастет. Но уже и сейчас нет проблем собрать с cmake на любой платформе(да и название намекает ). Или же нет?
Кстати, я сам мало использую проектов, которые на cmake построены. навскидку это avidemux и mysql

[eddy]

Но уже и сейчас нет проблем собрать с cmake на любой платформе(да и название намекает smile.gif ). Или же нет?

Да. Особенно если вы пишете с использованием gtk или кутей.

Кстати, я сам мало использую проектов, которые на cmake построены. навскидку это avidemux и mysql

locate -i cmakelist показал мне еще poppler, sox, libmini и bspline. Но это - лишь те, что были распакованы. Обычно после установки я распакованное дерево файлов удаляю.

Ну, а сам я подсел на cmake: использую уже в трех проектах (веб-авторизация + элементарные функции CGI, работа с ПЗС-матрицей, обработка FITS-файлов), плюс собираюсь четвертый переписать на cmake (все равно его почти полностью переписывать придется - это управление оптоволоконным спектрографом)

[Nazyvaemykh]

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

[watashiwa_daredeska]

3% - уже серьезно. Если учесть, что некоторые проекты переходят с autotools на cmake, то, возможно, это имеет смысл, что означает, что со временем доля проектов с cmake возрастет.

Скажем так, я сталкивался с необходимостью сборки OpenSource-проектов в не-GNU среде, где из доступного только posix shell (и прочие posix-инструменты), ANSI-compatible C compiler и некоторые библиотеки, вроде libx11. cmake с этим справится? Или проекты, использующие cmake, замыкают себя на linux+windows (ну, может macosx в последнее время еще)?

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

Еще один умник выискался. Подавляющее большинство проектов использует autotools и не жужжит. Сборщики этого софта в пакеты не жужжат. Пользователи пакетов не жужжат. Один вот, нет, два, умника жужжат, и не могут сформулировать, о чем жужжат. Всё им хочется каких-то непонятных нестандартных плюшек, которые будут работать на неопределенном нестандартном множестве систем. Хотя, о чем это я? Нет системы окромя Убунты, и всё, что работает в ней, работает везде, да.

[Bluetooth]

3% - уже серьезно. Если учесть, что некоторые проекты переходят с autotools на cmake, то, возможно, это имеет смысл, что означает, что со временем доля проектов с cmake возрастет.

Скажем так, я сталкивался с необходимостью сборки OpenSource-проектов в не-GNU среде, где из доступного только posix shell (и прочие posix-инструменты), ANSI-compatible C compiler и некоторые библиотеки, вроде libx11. cmake с этим справится? Или проекты, использующие cmake, замыкают себя на linux+windows (ну, может macosx в последнее время еще)?

А разве под другие posix совместимые оси отсутствует cmake?
Думаю, если бы это было так, то сборка, например, mysql на таких системах превратилась в увлекательное занятие
http://forge.mysql.com/wiki/CMake
http://www.cmake.org/cmake/resources/software.html - можно посмотреть, что список не ограничивается линукс и виндовс.
Впрочем, как-то обескураживает неупоминание bsd систем.
Я, как человек несведущий в этом деле, хотел бы, чтобы человек, более знакомый с cmake, уточнил мои данные про поддержку платформ, в первую очередь - bsd (:

[eddy]

я сталкивался с необходимостью сборки OpenSource-проектов в не-GNU среде, где из доступного только posix shell (и прочие posix-инструменты), ANSI-compatible C compiler и некоторые библиотеки, вроде libx11. cmake с этим справится?

В этом случае вы и без cmake ничего не соберете
Ну, а если сможете что-то собрать без cmake, то с cmake оно будет еще проще.

[IMB]

Ну, а если сможете что-то собрать без cmake, то с cmake оно будет еще проще.

Меня гложут смутные сомнения - магнитофон у Шпака, медальон у посла.© Иван Васильевич меняет профессию.
Сказывается то, что я никогда не интересовался этим вопросом, но во всех проектах использующих cmake я видел явное перечисление файлов, которые необходимо собрать.
vlc-qt-0.5.1

Код: Выделить всё

SET(VLCQT_SRCS
    core/Audio.cpp
    core/Common.cpp
    core/Enums.cpp
    core/Error.cpp
    core/Instance.cpp
    core/Media.cpp
    core/MediaPlayer.cpp
    core/MetaManager.cpp
    core/Video.cpp
    gui/AudioControl.cpp
    gui/SeekWidget.cpp
    gui/VolumeSlider.cpp
    gui/VideoControl.cpp
    gui/VideoWidget.cpp
)

В тоже время в проектах использующих make широко применяется подставление по маске.
TexasInstrumets

Код: Выделить всё

SOURCES = $(wildcard *.c) $(wildcard ../*.c)
HEADERS = $(wildcard *.h) $(wildcard ../*.h)
$(TARGET):      $(OBJFILES) $(XDC_LFILE)
        @echo
        @echo Linking $@ from $^..
        $(LINK.c) -o $@ $^

$(OBJFILES):    %.o: %.c $(HEADERS) $(XDC_CFLAGS)
        @echo Compiling $@ from $<..
        $(COMPILE.c) $(shell cat $(XDC_CFLAGS)) -o $@ $<

[kamre]

А posix shell'ом и make'ом пользоваться невозможно и ни в коем случае не надо — они есть у всех

Ну да, откуда posix shell и gnumake на windows. Так что пользоваться невозможно для кроссплатформенных проектов, которые еще и собирать нужно родным для платформы компилятором MSVC.

[kamre]

Сказывается то, что я никогда не интересовался этим вопросом, но во всех проектах использующих cmake я видел явное перечисление файлов, которые необходимо собрать.
...
В тоже время в проектах использующих make широко применяется подставление по маске.

Ничто не мешает использовать file(GLOB...) для поиска исходников по маске. Просто явное перечисление более удобно, т.к. CMake сам отслеживает то, что CMakeLists.txt был изменен, и перегенерирует Makefile/MSVC project.

[eddy]

Сказывается то, что я никогда не интересовался этим вопросом, но во всех проектах использующих cmake я видел явное перечисление файлов, которые необходимо собрать.

Я так не делаю:

Код: Выделить всё

aux_source_directory(. SOURCES)

Даже маску указывать не надо
А если надо какой-то файл удалить, то делаю так:

Код: Выделить всё

set(NOCUFILE ./NOCUDA.c)
if(CUDA_FOUND)
    list(REMOVE_ITEM SOURCES ${NOCUFILE})
...

[watashiwa_daredeska]

В этом случае вы и без cmake ничего не соберете

Собирал. Потому что проекты не требовали cmake.

Ну, а если сможете что-то собрать без cmake, то с cmake оно будет еще проще.

Не проще, ибо надо собрать еще саму cmake.

Однако, мы отвлеклись. Я, собственно, не говорю, что CMake — негодный инструмент. Я говорю, что autotools и make — НЕ негодные инструменты, как заявляет г-н eddy.

[Nazyvaemykh]

google://autohell
это не один-два умника, это довольно-таки массовое отношение к autotools.

[deadhead]

Я говорю, что autotools и make — НЕ негодные инструменты, как заявляет г-н eddy.

IMHO, он так вовсе не заявляет

А я так не говорю. Я просто говорю, что с cmake собирать намного проще, чем вручную писать длиннющие Makefile'ы или использовать медлительные autotools.

[watashiwa_daredeska]

на windows

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

Ежели б CMake умел генерить помимо Makefile еще и ./configure, то цены б ему не было.

[Nazyvaemykh]

Мусор, генерируемый autotools, может в разы превышать размеры самих исходных текстов, а время конфигурации — время самой компиляции. Для GNU bloatware это, может быть, и не плохо, для изящных программ в духе UNIX — сомневаюсь.

[eddy]

Я говорю, что autotools и make — НЕ негодные инструменты, как заявляет г-н eddy.

Где вы такие слова увидели?

Ежели б CMake умел генерить помимо Makefile еще и ./configure, то цены б ему не было.

Зачем? Это же вам не autotools, cmake сам делает то, что в autotools делает скрипт configure.

[watashiwa_daredeska]

IMHO, он так вовсе не заявляет

Советую дебильные autotools не использовать, а работать с cmake

make — наше всё·

Это только для проекта из одного файла годится.

А я так не говорю. Я просто говорю, что с cmake собирать намного проще, чем вручную писать длиннющие Makefile'ы или использовать медлительные autotools.

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

[watashiwa_daredeska]

Мусор, генерируемый autotools, может в разы превышать размеры самих исходных текстов, а время конфигурации — время самой компиляции.

Этот мусор и время меньше, чем время, необходимое на то, чтобы найти и собрать лишнюю сущность по имени CMake. Ну, не нужна эта штука пользователю совершенно.
Время конфигурации autotools зависит лишь от объема различных параметров, вариации которых разработчики заложили в программу. Думаю, если подобный объем вариаций заложить в cmakefile, то время конфигурации будет не сильно меньше.
А мусор… стоимость хранения 1GB мусора в течение 1 часа, пока я собираю бинарник, в современных условиях стремится к нулю экспоненциальными темпами.

[Kopilov]

Никто не упомянул Ant. Кто-нибудь его использует?