2009-10-28 6 views
2

У меня есть небольшое приложение ANSI C, которое компилируется под разными проверенными компиляторами и платформами. Он не использует никакого препроцессор переключателей или внешние зависимости и Makefile это просто что-то вроде:Должен ли я использовать automake/autoconf для распространения небольшого приложения ansi C?

myapp: *.c 
    gcc *.c -Wall -o myapp 

Если я хочу, чтобы распространить этот проект в виде исходного кода, как портативные, как это возможно, я должен обернуть его с помощью AutoMake/Autoconf? Будет ли это на самом деле увеличить переносимость или он будет настолько же портативным, как и он?

Единственное, что я могу думать, это то, что он автоматически выберет системный компилятор, но также добавит много сложности. Стоит ли оно того?

+1

В ' * .c 'обозначение - расширение GNU make - не обязательно доступно на платформах без GNU make. Лучше всего перечислить объектные файлы. –

ответ

4

Я сомневаюсь, что это того стоит. ANSI C без каких-либо вызовов, связанных с ОС, должен поддерживаться на каждой платформе с рабочим компилятором C и добавлением automake/autoconf, что делает обслуживание, вероятно, менее приятным, чем в настоящее время.

Вы можете, однако, использовать переменную $(CC) в вашем Makefile автоматически использовать компилятор системы:

myapp: *.c 
    $(CC) *.c $(CFLAGS) -o myapp 
+3

Я бы использовал '$ (CC)' вместе с '$ (CFLAGS)' и '$ (CPPFLAGS)' и '$ (LDFLAGS)' - и не оставлял '-Wall', как выглядит gcc. – ndim

+0

Согласен - не используйте autoconf. Обратите внимание на комментарий ndim. –

0

Хотя вы можете чувствовать себя вы получите мало с точки зрения функциональности, вы можете все еще хотите, чтобы рассмотреть это по следующим причинам:

  • Использование Autoconf является очень распространенным способом распространения кода C. Следовательно, большинству людей должно быть удобно создавать и устанавливать с помощью этого, что облегчает работу пользователя.
  • После того, как вы попытаетесь получить автоконфигурирование с вашим проектом, это значительно упростит, если и когда вы получите , выполните, чтобы использовать некоторые из его дополнительных функций.
+1

С другой стороны, если файл INSTALL (или, вернее, файл README) говорит: «Чтобы скомпилировать, запустите« make »- люди будут знать, что делать. –

+0

Вы абсолютно правы, и, в конце концов, это выбор автора. Тем не менее, у меня недавно была причина писать сценарий для автоматизации автоматической установки большого количества пакетов. Все те, которые использовали autoconf, нуждались в одном и том же лечении и относились к ним относительно просто. Пакеты, которые использовали что-то нестандартное, требовали индивидуального внимания и усилий и были настоящей неприятностью. – Tim

+0

Есть кое-что, что можно сказать о том, чтобы получить предсказуемые цели «make install» и «make uninstall» бесплатно. Если люди должны просто построить двоичный файл и запустить его, оставьте его как есть.Если люди установят двоичный файл, то я перейду к автотесту. –

4

Вам не нужно указать правило компиляции, таким образом, нет необходимости в $(CC), $(CFLAGS) и $(LDFLAGS), потому что make имеет неявное правило, чтобы сделать исполняемый файл из источника C.

Держите Makefile просто:

all: myapp 

myapp: *.c 

clean: 
    rm -f myapp 

.PHONY: all clean 

Кстати, было бы лучше, чтобы указать список исходных файлов, потому что нет никакой гарантии, что ваши источники будут только файлы C в этом каталоге