make определяет, что цель требует пересборки сравнивая её «время последней модификации» с аналогичным временем у её зависимостей. Не происходит анализа содержимого файла, только сравнение их времён. Но использование этой информации файловой системы не всегда надёжно, особенно в сетевом окружении. Системные часы могут отставать, иногда другие программы могут принудительно выставлять нужное им время модификации у файлов, затирая «настоящее» значение. Когда такое происходит, make не перестраивает цели, которые должны быть перестроены. В результате получается только частичная перекомпиляция.

Зависимость от параметров командной строки

Когда строка параметров какой-либо программы изменяется, её результаты также могут измениться (например, изменение в -Doption, которое передаётся в препроцессор языка C). make не будет перекомпилировать в этом случае, что приведёт к некорректной промежуточной перекомпиляции.

Вы можете попробовать защититься от этого, если внесёте в зависимость для каждой цели файл Makefile. Однако, этот подход ненадёжен, так как вы можете пропустить какую-нибудь цель. Более того, Makefile может включать другие Makefile’ы, которые тоже могут включать ещё Makefile’ы. Вы должны будете перечислить их все и поддерживать этот список в актуальном состоянии. Кроме того, многие изменения в makefile’ах являются незначительными. Вы, скорее всего, не хотите перекомпиляции всего проекта только из-за того, что вы изменили комментарий в makefile’е.

Наследование переменных окружения и зависимость от них

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

Множественные одновременные сессии

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

Редактирование файлов во время пересборки.

Если вы редактировали и сохранили файл во время работы make’а, то результат невозможно будет предсказать. Может быть, make корректно подхватит эти изменения, а может и нет — и вам надо будет запустить make снова. Или, если вам не повезло, сохранение может произойти в такой момент, что некоторые из целей потребуют пересборки, но последующие запуски make не обнаружат этого.

Удаление ненужных файлов

Предположим, ваш проект изначально использовал файл foo.c, но позже этот файл был удалён из проекта и из makefile’а. Временный объектный файл foo.o останется. Обычно, это допустимо, но такие файлы могут накапливаться с течением времени и иногда приводить к проблемам. Например, они могут быть ошибочно выбраны во время поиска по vpath. Другой пример: допустим один из файлов, ранее генерируемый make’ом во время сборки, теперь положен в систему версионного контроля. Правило, которое генерировало этот файл, также удалено из makefile’а. Однако, системы версионного контроля обычно не перезаписывают файлы, если видят, что не-версионный файл с таким же именем уже существует (из боязни удалить что-нибудь важное). Если вы не обратили внимание на сообщение о такой ошибке, не удалили этот файл вручную и не обновили повторно каталог с исходниками, то вы будете использовать устаревшую версию этого файла.

Нормализация имён файлов

К одному и тому же файлу можно обратиться, используя разные пути. Даже не беря во внимание жёсткие и символические ссылки, foo.c, ./foo.c, ../bar/foo.c, /home/user/bar/foo.c могут указывать на один и тот же файл. make’у следует обрабатывать их соответствующе, однако он этого не делает.
Проблема ещё хуже под Windows, где файловая система не регистро-зависима.

Последствия прерванной или сбойнувшей пересборки

Если сборка упала в середине процесса, дальнейшие инкрементальные перекомпиляции могут быть ненадёжными. В частности, если команда вернула ошибку, make не удаляет промежуточный выходной файл! Если вы запустите make снова, он может посчитать, что файл уже не требует перекомпиляции и попытаться использовать его. У make’а есть специальная опция, заставляющая его удалять такие файлы, но она не включена по-умолчанию.
Нажатие Ctrl-C во время пересборки также может привести ваше дерево исходников в непонятное состояние.
Каждый раз, когда вы сталкиваетесь с проблемами во время инкрементальной пересборки, возникает сомнение — если один файл не перестроился корректно, кто знает, сколько ещё есть таких файлов? В такой ситуации, возможно, вам надо начать заново с make clean. Проблема в том, что make clean не даёт никакой гарантии (см. выше), возможно, вам придётся разворачивать дерево исходников заново в другой директории.

Производительность

Производительность make’а масштабируется плохо (нелинейно) с ростом размера проекта.

Производительность инкрементальных сборок

Вы можете надеяться, что пересборка проекта занимает время пропорциональное числу целей, которые требуется перестроить. К сожалению, это не так.
Из-за того, что результат инкрементальных сборок не всегда внушает доверие, пользователи должны делать полную пересборку более-менее регулярно, иногда по необходимости (если что-то не собирается, попробуйте make clean; make), а иногда постоянно (из-за паранойи). Лучше быть уверенным и подождать полной пересборки, чем рисковать, что какая-то часть рассинхронизировалась с исходниками.
«Время последнего изменения» файла может измениться без изменения содержимого файла. Это приводит к ненужным перекомриляциям.
Плохо написанный makefile может содержать слишком много зависимостей, из-за этого цели могут перекомпилироваться даже если его (настоящие) зависимости не изменились. Неаккуратное использование «фальшивых» (phony) целей — это другой источник ошибок (такие цели всегда должны быть перестроены).
Даже если ваши makefile’ы не собержат ошибок, а ваши инкрементальные сборки абсолютно надёжны, производительность не идеальна. Предположим, вы редактировали один из .c-файлов (не заголовочный файл) в большом проекте. Если вы наберёте make в корне проекта, make должен будет распарсить все makefile’ы, рекурсивно вызывая себя много раз, и пройти по всем зависимостям, выясняя, нужно ли им перестраиваться. Время запуска собственно компилятора может быть существенно меньше общего времени.

Рекурсивный make и производительность

Небрежное использование рекурсивного make’а может быть опасно, например, при таком сценарии. Допустим, ваш проект содержит исходники двух исполняемых файлов A и B, которые в свою очередь, зависят от библиотеки C. Makefile самого верхнего уровня должен рекурсивно входить в директории A и B, конечно же. Нам также хотелось бы иметь возможность вызывать make в директориях A и B, если мы хотим построить только один из исполняемых файлов. Соответственно, мы должны рекурсивно вызывать make и из директории ../C. А если вызвать make из корня проекта, мы попадём в C дважды!
В данном примере это выглядит не страшно, но в больших проектах в некоторые директории make может заглядывать десятки раз. И каждый раз makefile должен быть прочитан, разобран и все его зависимости должны быть проверены. В make’е отсутствуют встроенные средства для предотвращения таких ситуаций.

Параллельный Make

«Параллельный запуск» make’а обещает большой прирост по скорости, особенно на современных процессорах с множеством ядер. К сожалению, реальность далека от обещаний.
Текстовый вывод «параллельного make’а» тяжело читать. Трудно увидеть какое предупреждение/строка/и т.п. относится к какой команде, когда несколько процессов одновременно работают в одном окружении.
Параллельный make особенно чувствителен к корректному указанию зависимостей. Если два правила не связаны через зависимости, make предполагает, что они могут быть вызваны в любом порядке. Когда вызывается одиночный make, его поведение предсказуемое: если A зависит от B и C, то сначала B будет построенно, затем C, потом A. Конечно, make имеет право построить C до В, но (в режиме последовательного make’а) порядок определён.
В параллельном режиме, B и C могут (но не обязаны) быть построены параллельно. Если C (на самом деле) зависит от B, но эта зависимость не прописана в makefile’е, то построение C, скорее всего, провалится (но не обязательно, зависит от конкретных времён).
Параллельный make выпячивает проблемы отсутствующих зависимостей в makefile’ах. Это само по себе хорошая вещь, т.к. они ведут к другим проблемам, и замечательно, что можно поймать их и исправить. Но на практике, на больших проектах, результат использования параллельного make’а разочаровывает.
Взаимодействие параллельного make’а с рекурсивным make’ом затруднительно. Каждая сессия make’а — независима, то есть каждая пытается распараллелить свою работу независимо от других и не имеет общего представления о полном дереве зависимостей. Мы должны найти компромис между надёжностью и производительностью. С одной стороны, мы хотим распараллелить сборку не только одного-единственного makefile’а, но и всех остальных makefile’ов. Но, так как make не знает о меж-makefile’ных зависимостях, полное распараллеливание суб-make’ов не работает.
Некоторые суб-make’и можно запускать параллельно, другие должны быть запущены в последовательном режиме. Указывать эти зависимости — неудобно, и очень легко пропустить несколько из них. Есть соблазн возврата к надёжному последовательному способу разбора дерева makefile’ов и распараллеливать только одиночные makefile’ы в каждый момент времени, но это сильно снижает итоговую производительность, в частности при инкрементальной сборке.

Автоматическая генерация зависимостей для Microsoft Visual C++

Многие компиляторы, как и GCC, могут выдавать информацию о зависимостях в формате, понимаемом make’ом. К сожалению, Microsoft Visual C++ не делает этого. У него есть специальный ключ /showIncludes, но требуется дополнительный скрипт, чтобы перевести эту информацию в формат make’а. Это требует запуска отдельного скрипта на каждый C-файл. Запуск, к примеру, интерпретатора Python’а для каждого файла — не мгновенная операция.

Встроенные правила

make содержит огромное количество встроенных правил. Они позволяют немного упростить код небольших makefile’ов, но средние и большие проекты обычно переопределяют их. Они влиют на производительность, так как make’у приходится пробираться через все эти дополнительные шаблоны пытаясь найти правила для компиляции файлов. Многие из них устарели — например, использование с RSC и SCCS системами ревизионного контроля. Их используют всего несколько человек, но эти правила будут замедлять все сборки всех остальных пользователей.
Вы можете отключить их с командной строки через make -r, но это не поведение по-умолчанию. Вы можете отключить их, добавив специальную директиву в makefile, но это тоже не по-умолчанию — и многие забывают сделать это.

Другое

Есть также и другие замечания к make’у, которые не попадают в предыдущие категории.

Молчание — золото

Согласно Эрику Реймонду, «одно из самых старых и неизменных правил дизайна мира UNIX’а является то, что если программе нечего сказать интересного или неожиданного — она должна молчать. Хорошо ведущие себя программы делают свою работу ненавязчиво, с минимумом требуемого внимания и беспокойства. Молчание — золото». make не следует этому правилу.
Когда вы запускаете make, его лог содержит все запускаемые им команды и всё, что выдают эти команды на stdout и stderr. Это слишком много. Важные предупреждения / ошибки тонут в этом потоке, а текст зачастую выводится так быстро, что становится нечитаемым.
Вы можете сильно уменьшить эту выдачу запуская make -s, но это не поведение по-умолчанию. Также, нет промежуточного варианта, при котором make выдаёт, что он сейчас делает — без печатания командных строк.

Многоцелевые правила

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

Предупреждения, которые должны быть ошибками

Make печатает предупреждения, но не прекращает работу, если он обнаруживает циклические зависимости. Это, скорее всего, свидетельствует о серьёзной ошибке в makefile’е, но make оценивает эту ситуацию как мелкую неприятность.
Аналогично, make печатает предупреждение (и продолжает работать дальше), если обнаруживает, что есть два правила, описывающих как сделать одну цель. Он просто игнорирует одно из них. И снова — это серьёзный баг в makefile’е, но make так не считает.

Создание директорий

Весьма удобно класть выходные файлы для разных конфигураций в разные директории, и вам не нужно будет перестраивать весь проект когда вы смените конфигурацию. К примеру, вы можете положить «debug» бинарники в каталог «debug» и аналогично для «release» конфигурации. Но до того, как вы начнёте класть файлы в эти директории, вы должны будете создать их.
Было бы здорово, если бы make делал это автоматически — очевидно же, что невозможно построить цель, если её директория пока не существует, — но make не делает этого.
Не является очень практичным вызывать mkdir -p $(dir $@)) в каждом правиле. Это неэффективно, а кроме того, вы должны игнорировать ошибку, если директория уже существует.
Вы можете попробовать решить проблему таким образом:

debug/%.o: %.c debug
       $(CC) -c $< -o $@
debug:
       mkdir $@



Выглядит работоспособным — если «debug» не существует, то создать его до начала компиляции debug/foo.o. Но только выглядит. Создание нового файла в директории изменяет «время последней модификации» этой директории. Допустим, мы компилируем два файла — debug/foo.o и debug/bar.o. Создание debug/bar.o изменит время модификации директории «debug». Теперь оно станет более новым, чем время создания debug/foo.o, то есть, в следующий раз, когда мы вызовём make, файл debug/foo.o будет перекомпилирован без необходимости. А если перекомпиляция делается через удаление старого файла и создания нового (а не через перезапись существующего файла), вы получите нескончаемую череду ненужных перекомпиляций.
Решением является создание зависимости от файла (например, debug/dummy.txt), а не от директории. Это требует дополнительных действий в makefile’е (touch debug/dummy.txt), и может конфликтовать с возможностью make’а по автоматическому удалению промежуточных файлов. А если же вы не будете аккуратны в указании этой дополнительной зависимости (от dummy.txt) для каждой цели, вы получите проблемы, когда запустите make в параллельном режиме.

Выводы

Make — популярная утилита с множеством изъянов. Она может упростить вам жизнь, а может и усложнить её. Если вы работаете над большим программным продуктом, вы должны рассмотреть и другие альтернативы make’у. Если же вы должны использовать только make, вы должны быть в курсе его недостатков.

PS: всё вышесказанное — перевод вот этой статьи. Я давно собирался написать топик на такую же тему, но прочитав статью, понял, что лучше будет сделать перевод. Не все аргументы автора «make-специфичны» (а некоторые вообще подойдут к абсолютно всем утилитам подобного рода), но знание и понимание различных грабель make'а необходимо всем программистам, которым приходится использовать его в своей работе.

tl;dr

> в нём используются табуляции

Хе-хе-хе

Why the tab in column 1? Yacc was new, Lex was brand new. I hadn't tried either, so I figured this would be a good excuse to learn. After getting myself snarled up with my first stab at Lex, I just did something simple with the pattern newline-tab. It worked, it stayed. And then a few weeks later I had a user population of about a dozen, most of them friends, and I didn't want to screw up my embedded base. The rest, sadly, is history.

что за хуйня у нано со специальными символами

по ssh подключился

еще в zsh русский отказывается писать

это выглядит вот так

лол

Оhyou

сам спросил - сам ответил? :)

Шалом. \о

Шолом алейхем