Преимущества использования автоинструментов и альтернатив
У меня есть умеренный проект C ++. Я пытаюсь использовать для этого автоинструменты, но сложность оказывается подавляющей.
Каковы рекомендации, когда использовать автоинструменты и когда можно обойтись без него? Каковы (простые) альтернативы?
Основная причина, по которой я хочу использовать автоинструмент, заключается в его полной make install служба поддержки. Есть ли более простая альтернатива?
В идеале мне бы хотелось, чтобы что-то поддерживалось Eclipse CDT.
Решение
Для make install поддержка, вам нужно только automake, И простой Makefile.am Файл довольно легко сделать:
LIBS += -lsome-lib -lsome_other_lib
bin_PROGRAMS = hello
noinst_HEADERS = some.h header.h files.h
hello_SOURCES = hello.c some.c other.c source.c file.c
Вот и все.
autoconf Инструмент полезен, если вы хотите сделать вашу программу более независимой от платформы. Вы пишете простой скрипт для проверки существования файлов заголовков системы и используемых вами системных библиотек. Если не найдено, вы либо выдаете ошибку, либо используете копии, предоставленные в вашем пакете.
Другие решения
Для тривиальных, автономных (без зависимостей, ничего не устанавливаемых) проектов, содержащих до 3 файлов исходного кода, напишите Makefile:
.PHONY: all clean
all: program
clean:
rm -f *.o
program: sourceA.o sourceB.o
$(CXX) -o $@ $^ $(LDFLAGS)
Вы можете определить переменные для CPPFLAGS, CFLAGS, CXXFLAGS, LDFLAGS, по крайней мере, GNU заполняет пробелы ожидаемым образом.
Конечно, это не решает проблему отслеживания зависимостей и проверки возможностей системы. Распространенной проблемой для нетривиальных проектов является взаимодействие с системой: обеспечение возможности использования определенных библиотек и установка / удаление. Большинство инструментов терпят неудачу на обоих.
Вот несколько примеров, с которыми я имею опыт работы:
Он генерирует согласованные файлы проекта для разных IDE (а также Makefiles, если вам просто нужно собрать код). Больше ничего не делает (нет цели установки, нет возможности проверить наличие библиотек). Полезно, только если вам нужно предоставить файлы проекта для IDE, которую вы не используете (например, вы используете Eclipse, а кто-то еще хочет скомпилировать его в Visual Studio). Все, что нетривиально, требует сценариев LUA.
Если все, что вам нужно, это вызвать компилятор для обработки ваших файлов, это приемлемо. Почти для всего вам нужно запомнить (или скопировать / вставить) последовательности низкоуровневых макросов (которые образуют своего рода язык программирования). Поиск библиотек в системе сложен и запутан (некоторые библиотеки были благословлены создателями и имеют жестко запрограммированные тесты для их поиска, так что вам может повезти). Учитывая количество разбитых скриптов cmake, с которыми мне приходилось сталкиваться на сегодняшний день, я думаю, что большинство людей просто копируют / вставляют макросы, не пытаясь понять это. Можно установить, но не удалить. С некоторыми сценариями cmake вам, возможно, придется запускать cmake несколько раз, пока он не выдаст правильный вывод (например, VTK).
Кажется, что CMAKE и Premake сделаны лучше: нет макросов, используется хорошо известный язык программирования (Python) для обеспечения достаточного количества полезных функций. Все еще терпит неудачу во многих отношениях; указание не жестко заданного префикса установки требует нетривиальных усилий, поскольку оно не является встроенным.
Делает намного больше, чем инструменты, упомянутые выше. И большинство из них, удобно. Имеет нормальные значения по умолчанию; некоторые основные моменты:
-
AC_CHECK_LIB(foobar, function_to_check_linking)— это находит библиотеку с именем foobar и помещает ее в$LIBSпеременная окружения. Да, обнаружение библиотек является важной общей задачей; если ваш инструмент не считает это первоклассным вариантом использования, откажитесь от него. (Хотя более удобно использовать PKG_CHECK_MODULES.) -
Каждое действие во время
./configureвошел вconfig.logТаким образом, вы можете понять, что пошло не так. Для большинства других инструментов в лучшем случае вы получите «Boost_dir-NOTFOUND». -
Уже поставляется со встроенным
make install,make uninstall(что вы имеете в виду, ваш инструмент может помещать материалы в мою систему, но не может их удалять?),make check(если вы указалиtest_программы),make dist-gzip(упаковывает исходные файлы в tar.gz),make distcheck(создает tar.gz и проверяет, что все работает правильно и все тесты пройдены). Еще лучше, это играет хорошо сcheckinstallтак что вы можете создавать и распространять .rpms и .debs из него. -
При необходимости вы можете смешивать старые добрые правила Makefile внутри automake Makefiles.
-
Файлы автоинструментов отслеживаются так же, как и исходные файлы, поэтому вспомогательные сценарии и файлы Makefile генерируются снова, если это необходимо, просто вызывая
make,
Да, это «сложно» изучить, но, на мой взгляд, не более чем изучение всех конкретных макросов / функций, вызываемых в CMAKE / SCons. Начальный Makefile.am для проекта это просто список файлов, назначенных переменной, и начальный configure.ac может быть создан autoscan; Я нахожу это удобным даже для более тривиальных проектов.
AUTOBook лучший источник, который я знаю, чтобы узнать его, но он, к сожалению, устарел (autoconf будет много жаловаться на использование устаревших макросов).
Вы можете выбрать те части автоинструментов, которые вы хотите использовать. Многие проекты используют только autoconfчасть автоинструментов, которая генерирует configure сценарий, и если вы просто хотите сгенерировать Makefile с install цель, которая настраивается конечным пользователем, тогда это, вероятно, все, что вам нужно.
Я не знаю, слишком ли это далеко от ответа, но я бы подумал о булочках. Чтобы начать работу, требуется немного времени, но автоматически происходит много-много вещей, которые нужно дразнить вручную с помощью make.
detector