Лучшие проверщики и линтеры Makefile

Проверщик Makefile - инструмент статического анализа, который читает ваш Makefile и проверяет его по грамматическим правилам GNU Make до выполнения любой команды shell. В отличие от make --dry-run, проверщику не нужны среда сборки, установленные инструменты или корректные исходники - он работает чисто с текстом Makefile.

Что проверяется

Поверхность валидации хорошего проверщика охватывает три слоя. Синтаксическая валидация подтверждает, что правила целей следуют правильному формату, строки рецептов начинаются с символов TAB, а присваивания переменных используют допустимые операторы. Валидация зависимостей строит граф предпосылок и проверяет, что каждая зависимость ссылается на определённую цель или реальный файл. Семантическая валидация помечает паттерны, которые технически допустимы, но надёжно приводят к проблемам - как отсутствие объявлений .PHONY у не-файловых целей.

• Синтаксический слой - формат правил целей, рецепты с отступами TAB, операторы присваивания переменных (`=`, `:=`, `?=`, `+=`)
• Слой зависимостей - неразрешённые предпосылки, неопределённые цели и циклические цепочки зависимостей
• Семантический слой - отсутствующие объявления `.PHONY`, дублирующиеся определения целей и пустые блоки рецептов
• Слой стиля - непоследовательные отступы, длинные строки и нарушения соглашений об именовании (обрабатываются линтерами вроде checkmake)

Большинство сбоев Makefile происходит из небольшого набора повторяющихся ошибок. Понимание каждой помогает знать, что искать, когда проверщик сообщает о проблеме - и почему это важно.

Отступы TAB против пробелов

Самая распространённая ошибка Makefile - и самая запутанная: строки рецептов должны начинаться с символа TAB, а не с пробелов. GNU Make был создан в 1976 году, и требование TAB никогда не отменялось. Современные редакторы по умолчанию используют пробелы, и многие незаметно превращают табуляцию в пробелы при сохранении. В результате Makefile выглядит идеально отформатированным на экране, но падает с загадочной ошибкой «missing separator» во время выполнения.

build:
    gcc -o app main.c   # ← отступ из 4 пробелов - make это отвергнет

build:
	gcc -o app main.c   # ← отступ табуляцией - правильно

Неразрешённые предпосылки

Когда цель перечисляет предпосылку, которая не соответствует ни определённой цели, ни существующему файлу, make либо незаметно пропускает зависимость, либо падает с «No rule to make target». Проверщик находит это на этапе статического анализа, строя полный граф зависимостей и помечая все висячие ссылки до выполнения хоть одной команды.

Циклические зависимости

Циклическая зависимость возникает, когда цель A зависит от B, а B (прямо или косвенно) зависит от A. GNU Make печатает предупреждение и отбрасывает циклическое правило - часть вашей сборки незаметно не выполняется. Проверщики, строящие граф зависимостей, обнаруживают циклы до выполнения и сообщают точные задействованные цели - чего предупреждение make не показывает ясно на длинных цепочках.

Отсутствующие объявления .PHONY

Цели вроде clean, test, all и install - условные имена, не создающие выходных файлов. Без объявления .PHONY make проверяет, существует ли файл с именем «clean» в каталоге. Если существует, make считает цель актуальной и полностью пропускает её рецепт - без ошибки, без вывода, просто тихий сбой. Каждая не-файловая цель должна быть указана в .PHONY.

Браузерные проверщики Makefile - самый быстрый способ валидировать файл, ничего не устанавливая. Они полезны для быстрой проверки, для разработчиков в средах, где нельзя установить CLI-инструменты, или для ревью Makefile, присланного кем-то.

Не существует единственного «лучшего» проверщика Makefile на все случаи. Правильный инструмент зависит от того, нужна ли вам быстрая разовая проверка, интеграция в CI-пайплайн или обратная связь редактора в реальном времени. Вот как соотносятся основные варианты.

Строки рецептов должны начинаться с символа табуляции. Это давнее требование GNU Make, которое не может обойти никакая утилита или настройка IDE по умолчанию - только правильная конфигурация редактора или статический проверщик обнаружит проблему раньше make.

Makefile Syntax and Dependency Checker от Aback Tools

Проверщик Aback Tools - лучший вариант, когда нужны мгновенные результаты без какой-либо настройки. Он валидирует синтаксис, отступы TAB, разрешение предпосылок и графы циклических зависимостей полностью в браузере. Без установки, без загрузки на сервер, без логина. Особенно полезен для ревью Makefile в средах, где нельзя установить CLI-инструменты - удалённые машины, шаги ревью в CI или общие среды с ограниченными правами.

checkmake (CLI)

checkmake - CLI-линтер с открытым кодом на Go, доступен на GitHub под mrtazz/checkmake. Он сосредоточен на принуждении стиля и соглашений: минимальные объявления phony-правил, максимальная длина строки, наличие описаний целей и шаблоны именования. Лёгкий и быстрый, идеален для pre-commit-хуков или CI-процессов, где нужно автоматически поддерживать общекомандные соглашения Makefile.

Расширение VS Code Makefile Tools

Официальное расширение Makefile Tools от Microsoft для VS Code даёт IntelliSense в реальном времени для целей и переменных, подсветку ошибок в строке для распространённых синтаксических проблем и панель проводника целей. Лучший выбор для разработчиков, часто пишущих Makefile и желающих нативную обратную связь редактора без перехода на отдельный инструмент. Оно не валидирует графы зависимостей так глубоко, как специализированный проверщик, но мгновенно ловит большинство повседневных ошибок.

make --dry-run (встроенный)

make -n или make --dry-run выполняет логику сборки без запуска команд shell. Полезно для проверки, что выбираются правильные цели и команды, но требует полной среды сборки - все предпосылки должны быть выполнены, а инструмент не даёт структурированного вывода ошибок. Используйте как финальную проверку после того, как специализированный проверщик уже валидировал структуру файла.

Добавление валидации Makefile в CI-пайплайн не даёт регрессиям влиться незаметно. Настройка лёгкая - один шаг workflow, который валит сборку, если проверщик сообщает об ошибках.

GitHub Actions с checkmake

checkmake доступен как предкомпилированный бинарник для Linux и macOS, что упрощает установку в раннере GitHub Actions. Добавьте job, который устанавливает бинарник и запускает его на вашем Makefile - шаг падает с ненулевым кодом выхода при нарушениях правил, блокируя мерж pull request.

name: Lint Makefile

on:
  pull_request:
    paths:
      - 'Makefile'
      - '**/Makefile'

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install checkmake
        run: |
          curl -sSfL https://github.com/mrtazz/checkmake/releases/latest/download/checkmake-linux-amd64 \\
            -o /usr/local/bin/checkmake
          chmod +x /usr/local/bin/checkmake

      - name: Run checkmake
        run: checkmake Makefile

Pre-commit-хук

Для локального принуждения ещё до попадания кода в CI добавьте pre-commit-хук, запускающий checkmake на изменениях Makefile в индексе. Фреймворк pre-commit поддерживает это нативно и чисто интегрируется с любым Git-процессом.

repos:
  - repo: local
    hooks:
      - id: checkmake
        name: Lint Makefile
        language: system
        entry: checkmake
        files: ^Makefile$|/Makefile$
        pass_filenames: true

Запуск проверщика после написания Makefile - это страховочная сетка. Правильное написание Makefile с самого начала - практика, при которой сетка редко нужна. Эти привычки устраняют самые частые ошибки до их появления.

Настройте редактор на отступы TAB

Каждому редактору с пробелами по умолчанию нужна явная настройка, чтобы использовать TAB в файлах Makefile. В VS Code добавьте настройку workspace или языка, которая вставляет литеральные символы TAB при работе с файлами Makefile. В Vim и Neovim паттерн autocmd для файлов Makefile стандартен и хорошо документирован. В IDE JetBrains файлы Makefile автоматически распознаются и получают отступы TAB.

{
  "[makefile]": {
    "editor.insertSpaces": false,
    "editor.detectIndentation": false
  }
}

Всегда объявляйте .PHONY для не-файловых целей

Перечислите под .PHONY в начале Makefile каждую цель, не создающую выходного файла. Условный список включает all, clean, install, test, lint, build, run и любое другое целевое действие вашего проекта. Это одна из важнейших конвенций Makefile - и checkmake принуждает её по умолчанию.

• Объявляйте .PHONY заранее - поместите её ближе к началу Makefile, чтобы её видели каждый читатель и каждый проверщик
• Включайте все целевые действия - любая цель, рецепт которой вы всегда хотите выполнять независимо от состояния файлов, принадлежит .PHONY
• Используйте одно объявление .PHONY - перечислите все phony-цели одним блоком, а не отдельными объявлениями по файлу
• Документируйте цель по умолчанию - первая цель в Makefile является целевой по умолчанию; назовите её `all` и задокументируйте, что она собирает
• Префиксуйте отладочные цели - внутренние или отладочные цели вроде `debug-vars` или `print-PATH` реже конфликтуют с реальными файлами при префиксе

Держите предпосылки плоскими и явными

Глубокие цепочки предпосылок труднее валидировать и легче сломать. По возможности держите граф зависимостей мелким - один-два уровня - и ссылайтесь на файлы явно, а не полагайтесь на неявные правила. Неявные pattern-правила вроде `%.o: %.c` - валидный синтаксис GNU Make, но статическим проверщикам их труднее полностью разрешить, и граф зависимостей становится менее очевидным для читающих файл.

Статические проверщики Makefile мощны, но работают с текстом файла. Они не видят состояние во время выполнения, содержимое файловой системы и доступность инструментов. Существуют категории проблем Makefile, которые ни один проверщик не найдёт статически.

Неопределённые переменные разворачиваются молча

В GNU Make ссылка на неопределённую переменную разворачивается в пустую строку без какой-либо ошибки. Рецепт, который должен был выполнить gcc $(CFLAGS) -o app main.c, выполнит gcc -o app main.c, если CFLAGS не определена - возможно, компиляция пойдёт без нужных флагов, и бинарник заработает локально, но упадёт в продакшене. Проверщик не может знать ваше задуманное значение CFLAGS, поэтому эта категория багов требует тестирования во время выполнения или условных проверок переменных в самом Makefile.

Разрешение неявных правил во время выполнения

У GNU Make большой набор встроенных неявных правил - автоматические способы компиляции .c в .o, линковки объектных файлов и т.д. Статический проверщик не симулирует эти правила, поэтому Makefile, сильно опирающийся на неявные правила, может пройти проверку чисто, но упасть во время выполнения, если предполагаемые инструменты не установлены. Явные правила с определёнными рецептами всегда безопаснее и портируемее.

Зависимости от состояния файловой системы

Цели, зависящие от файлов, генерируемых более ранними целями - объектные файлы, скомпилированные заголовки, сгенерированный исходный код - корректны во время выполнения, но не могут быть валидированы статически, потому что файлов-предпосылок ещё не существует, пока make не запустится. Для таких случаев make --dry-run в сочетании с полной средой сборки - правильное дополнение к статическому проверщику. Два подхода покрывают разные режимы отказа и наиболее эффективны вместе.