Comments 33
Вот бы кто automake и autoconf разжевал.
Если вы начинаете новый проект, а не вынуждены поддерживать существующее — обходите automake и autoconf за милю :) Есть множество альтернатив — cmake, scons итд — разработчиков которых хотя бы не хочется четвертовать.
Нельзя ли поподробней, что такого ужасного в GNU Autotools? Я использовал их в нескольких проектах с самого начала и по большому счету ни разу не пожалел, хотя приходилось писать небольшие куски на m4, а также возникали определенные неудобства, когда хотелось странного.
m4 ужасен. divert — это вообще за гранью добра и зла.
Для небольших проектов, где ничего особенного не нужно, все выглядит неплохо, но… Попробуйте на досуге разобраться в autoconf-е php ;)
Для небольших проектов, где ничего особенного не нужно, все выглядит неплохо, но… Попробуйте на досуге разобраться в autoconf-е php ;)
Я бы сказал, что m4 странен, а divert мне не понадобился (повезло наверно), поэтому я не знаю, что это такое. Сколь-нибудь нетривиальную макруху приходилось писать для Charm++ и для CUDA. В первом случае, насколько я помню, было всё гладко, а во втором осталось какое-то несовершенство, но терпимое. Правда, мои коллеги боялись даже заглядывать во все эти тексты и осторожно ковыряли только am-мейкфайлы. Наверно, действительно, порог вхождения высок.
есть куча переведенных туториалов
Если уж заикнулись про зависимости, рассказали бы про makedepend
www.galassi.org/mark/mydocs/autoconf_tutorial_1.html
www.freesoftwaremagazine.com/books/autotools_a_guide_to_autoconf_automake_libtool
Нужно что-то типа реферата по этим материалам?
www.freesoftwaremagazine.com/books/autotools_a_guide_to_autoconf_automake_libtool
Нужно что-то типа реферата по этим материалам?
Нет конечно, вы что
Неправильно выразился. На основе толстых талмудов сделать компактный легкоусвояемый туториал вроде вот этого. Или первый комментатор использовал sarcasm mode on?
1. Это сделать полезно и нужно
2. Такие вопросы надоели уже
2. Такие вопросы надоели уже
Вопросы про реферат или про сарказм? Я еще атмосферу ресурса не очень улавливаю, поэтому спрашиваю глупости
Для цели clean все же лучше указывать точку перед о (rm -rf *.o)
Вместо
Лучше писать:
$@ — имя .o-файла
$< — имя .cpp-файла
Такое правило будет автоматом работать для всех .o-файлов, указанных в качестве зависимостей цели.
main.o: main.cpp
g++ -c main.cpp
factorial.o: factorial.cpp
g++ -c factorial.cpp
hello.o: hello.cpp
g++ -c hello.cpp
Лучше писать:
.SUFFIXES: .cpp .o
.cpp.o:
$(CC) $(CFLAGS) -c -o $@ $<
$@ — имя .o-файла
$< — имя .cpp-файла
Такое правило будет автоматом работать для всех .o-файлов, указанных в качестве зависимостей цели.
Ровно до тех пор, пока не появится необходимость подключить проекту объектный модуль. Соответственно, для этого модуля не будет .cpp-файла. Более того, может появится необходимость подключить один единственный файл .c и make тоже поломается.
Вы даже не проверяли то, о чём говорите.
Убираю из списка целей z.o, добавляю x.o — всё прекрасно собирается.
Ровно до тех пор, пока не появится необходимость подключить проекту объектный модуль. Соответственно, для этого модуля не будет .cpp-файла.Только что создал файл x.c, вручную скомпилировал в z.o, и добавил z.o в список целей сборки одного моего личного проекта — собирается нормально, никаких проблем у make не возникло со сборкой. Я даже успешно вызвал из кода на D функцию из z.o.
Более того, может появится необходимость подключить один единственный файл .c и make тоже поломается.Опять же, никаких проблем:
.d.o:
$(D_COMPILER) $(D_COMPILER_FLAGS) -c -of$@ $<
.c.o:
$(CC) $(CFLAGS) -c -o $@ $<
Убираю из списка целей z.o, добавляю x.o — всё прекрасно собирается.
Если изменятся заголовочные файлы, ваш мейкфайл ничего не пересоберёт.
программа попытается найти файл с именем по умолчание makefile
Это юникс, здесь важен регистр букв. make пытается найти файл с именем по умолчанию Makefile
Это юникс, здесь важен регистр букв. make пытается найти файл с именем по умолчанию Makefile
позорно протупил. Конечно же так правильно. Исправляю
Если речь идет о GNU Make, то по умолчанию проверяются три файла, по порядку: GNUmakefile -> makefile -> Makefile.
Другое дело, что в документации рекомендуется использовать именно Makefile, чтобы в листинге директории видеть его сверху. Пруф.
Другое дело, что в документации рекомендуется использовать именно Makefile, чтобы в листинге директории видеть его сверху. Пруф.
До сих пор пользовался скриптом на баше, чтобы компилировать большое количество файлов. Спасибо за перевод, давно хотел изучить этот вопрос.
Еще бы показали, как одинм make-файлом собирать проекты написаные частично на С, частично на С++.
как_нарисовать_сову.jpg
.cpp.o:
$(CC) $(CFLAGS) $< -o $@
Makefile-4
Успехов!
Пока в комментах не разживали, что такое $< и $@ ничего не было понятно. Да и после того всё придельно ясно не стало. Зачем вообще было упоминать эти токены, если они не рассказали?
$(CC) $(CFLAGS) $< -o $@
Makefile-4
Успехов!
Пока в комментах не разживали, что такое $< и $@ ничего не было понятно. Да и после того всё придельно ясно не стало. Зачем вообще было упоминать эти токены, если они не рассказали?
В первом примере цель называется all. Это цель по умолчанию для мейкфайла, которая будет выполняться, если никакая другая цель не указана явно.Тут злостно нарушена причинно-следственная связь!
На самом деле, «по умолчанию» цель выбирается не «all», а просто первая цель в Makefile'е.
Называться-то она может вообще как угодно:
firsttarget:
echo "The first one is the default"
all:
echo "All is the default"
Проверяем:
$ make
echo "The first one is the default"
The first one is the default
Понимаю, что это перевод, но своя голова-то тоже не бывает лишней :-)
Из той же серии:
all:
g++ main.cpp hello.cpp factorial.cpp -o hello
— правилом хорошего тона вроде как считается называть цель так же, как называется результат выполняния команд (hello).
Могу поверить, что стилистическая ошибка в последнем примере обусловлена непониманием, описанным выше.
Sign up to leave a comment.
Makefile для самых маленьких