Как стать автором
Обновить

Комментарии 33

Вот бы кто automake и autoconf разжевал.
I saw a book entitled «Die GNU Autotools» and I thought «My feelings exactly». Turns out the book was in German. [via]
Если вы начинаете новый проект, а не вынуждены поддерживать существующее — обходите automake и autoconf за милю :) Есть множество альтернатив — cmake, scons итд — разработчиков которых хотя бы не хочется четвертовать.
Нельзя ли поподробней, что такого ужасного в GNU Autotools? Я использовал их в нескольких проектах с самого начала и по большому счету ни разу не пожалел, хотя приходилось писать небольшие куски на m4, а также возникали определенные неудобства, когда хотелось странного.
m4 ужасен. divert — это вообще за гранью добра и зла.

Для небольших проектов, где ничего особенного не нужно, все выглядит неплохо, но… Попробуйте на досуге разобраться в autoconf-е php ;)
Я бы сказал, что m4 странен, а divert мне не понадобился (повезло наверно), поэтому я не знаю, что это такое. Сколь-нибудь нетривиальную макруху приходилось писать для Charm++ и для CUDA. В первом случае, насколько я помню, было всё гладко, а во втором осталось какое-то несовершенство, но терпимое. Правда, мои коллеги боялись даже заглядывать во все эти тексты и осторожно ковыряли только am-мейкфайлы. Наверно, действительно, порог вхождения высок.
есть куча переведенных туториалов
Если уж заикнулись про зависимости, рассказали бы про makedepend
Нет конечно, вы что
Неправильно выразился. На основе толстых талмудов сделать компактный легкоусвояемый туториал вроде вот этого. Или первый комментатор использовал sarcasm mode on?
1. Это сделать полезно и нужно
2. Такие вопросы надоели уже
Вопросы про реферат или про сарказм? Я еще атмосферу ресурса не очень улавливаю, поэтому спрашиваю глупости
На ресурсе часто можно встретить вопросы из разряда «А нужна ли статья про..» и, по моим наблюдениям, на такие вопросы всегда отвечают, что да, нужна, делайте. Зачем тогда такие бесполезные вопросы? Если можете сделать хорошую статью о чем-то, то просто сделайте.
Для цели clean все же лучше указывать точку перед о (rm -rf *.o)
Исправил в посте и в архиве проекта
А для цели fun просто писать * без ".o"
Скорее для цели mazo :)
Вместо

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 тоже поломается.
Вы даже не проверяли то, о чём говорите.

Ровно до тех пор, пока не появится необходимость подключить проекту объектный модуль. Соответственно, для этого модуля не будет .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 — всё прекрасно собирается.
Если изменятся заголовочные файлы, ваш мейкфайл ничего не пересоберёт.
Я очень порекомендую вам premake (среди тулзов cmake, qmake, premake он мне понравился больше всего). Хотя последняя версия вышла 16 ноября 2010, так что, возможно, он не очень живой.
программа попытается найти файл с именем по умолчание makefile

Это юникс, здесь важен регистр букв. make пытается найти файл с именем по умолчанию Makefile
позорно протупил. Конечно же так правильно. Исправляю
Если речь идет о GNU Make, то по умолчанию проверяются три файла, по порядку: GNUmakefile -> makefile -> Makefile.

Другое дело, что в документации рекомендуется использовать именно Makefile, чтобы в листинге директории видеть его сверху. Пруф.
До сих пор пользовался скриптом на баше, чтобы компилировать большое количество файлов. Спасибо за перевод, давно хотел изучить этот вопрос.
Еще бы показали, как одинм make-файлом собирать проекты написаные частично на С, частично на С++.

g++ для .cpp
gcc для .c
отдельно собираем объектники .o для .cpp-кода через g++, и отдельно объектники сишек. Потом собираем общий elf a.out.
Поправьте, если что не так, я еще плохо шарю.

как_нарисовать_сову.jpg
.cpp.o:
$(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).
Могу поверить, что стилистическая ошибка в последнем примере обусловлена непониманием, описанным выше.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории