- Что такое Makefile и как начать его использовать
- Введение
- Что такое make и Makefile
- Синтаксис Makefile
- Продвинутое использование
- Фальшивая цель
- Последовательный запуск команд и игнорирование ошибок
- Переменные
- Заключение
- Дополнительные материалы
- Просто о make
- Make- основные сведения
- Простейший Makefile
- Компиляция из множества исходников
- Инкрементная компиляция
- Фиктивные цели
- Переменные
- Автоматические переменные
- Getting Started
- Why do Makefiles exist?
- What alternatives are there to Make?
- Running the Examples
- Makefile Syntax
- Beginner Examples
- Variables
- Targets
- The all target
- Multiple targets
- Automatic Variables and Wildcards
- * Wildcard
- % Wildcard
- Automatic Variables
- Fancy Rules
- Static Pattern Rules
- Static Pattern Rules and Filter
- Implicit Rules
- Pattern Rules
- Double-Colon Rules
- Commands and execution
- Command Echoing/Silencing
- Command Execution
- Default Shell
- Error handling with -k , -i , and —
- Interrupting or killing make
- Recursive use of make
- Use export for recursive make
- Arguments to make
- Variables Pt. 2
- Flavors and modification
- Command line arguments and override
- List of commands and define
- Target-specific variables
- Pattern-specific variables
- Conditional part of Makefiles
- Conditional if/else
- Check if a variable is empty
- Check if a variable is defined
- $(makeflags)
- Functions
- First Functions
- String Substitution
- The foreach function
- The if function
- The call function
- The shell function
- Other Features
- Include Makefiles
- The vpath Directive
- Multiline
- .phony
- .delete_on_error
- Makefile Cookbook
Что такое Makefile и как начать его использовать
Введение
В жизни многих разработчиков найдётся история про первый рабочий день с новым проектом. После клонирования основного репозитория проекта наступает этап, когда приходится вводить множество команд с определёнными флагами и в заданной последовательности. Без описания команд, в большинстве случаев, невозможно понять что происходит, например:
Эти команды являются лишь частью того, что необходимо выполнить при разворачивании проекта. В приведённом примере видно, что команды сами по себе длинные, содержат много флагов, а значит, их трудно не только запомнить, но и вводить вручную. Постоянно вести документацию становится сложнее с ростом проекта, она неизбежно устаревает, а порог входа для новичков становится выше, ведь уже никто не в состоянии вспомнить всех деталей проекта. Некоторые такие команды необходимо использовать каждый день, и даже не один раз в день.
Со временем становится понятно, что нужен инструмент, способный объединить в себе подобные команды, предоставить к ним удобные шорткаты (более короткие и простые команды) и обеспечить самодокументацию проекта. Именно таким инструментом стал Makefile и утилита make . Этот гайд расскажет, как использование этих инструментов позволит свести процесс разворачивания проекта к нескольким коротким и понятным командам:
Что такое make и Makefile
Makefile — это файл, который хранится вместе с кодом в репозитории. Его обычно помещают в корень проекта. Он выступает и как документация, и как исполняемый код. Мейкфайл скрывает за собой детали реализации и раскладывает “по полочкам” команды, а утилита make запускает их из того мейкфайла, который находится в текущей директории.
Изначально make предназначалась для автоматизации сборки исполняемых программ и библиотек из исходного кода. Она поставлялась по умолчанию в большинство *nix дистрибутивов, что и привело к её широкому распространению и повсеместному использованию. Позже оказалось что данный инструмент удобно использовать и при разработке любых других проектов, потому что процесс в большинстве своём сводится к тем же задачам — автоматизация и сборка приложений.
Применение мейка в проектах стало стандартом для многих разработчиков, включая крупные проекты. Примеры мейкфайла можно найти у таких проектов, как Kubernetes, Babel, Ansible и, конечно же, повсеместно на Хекслете.
Синтаксис Makefile
make запускает цели из Makefile, которые состоят из команд:
Но недостаточно просто начать использовать мейкфайл в проекте. Чтобы получить эффект от его внедрения, понадобится поработать над разделением команд на цели, а целям дать семантически подходящие имена. Поначалу, перенос команд в Makefile может привести к свалке всех команд в одну цель с «размытым» названием:
Здесь происходит сразу несколько действий: создание файла с переменными окружения, подготовка базы данных, генерация ключей, установка зависимостей и запуск проекта. Это невозможно понять из комментариев и названия цели, поэтому будет правильно разделить эти независимые команды на разные цели:
Теперь, когда команды разбиты на цели, можно отдельно установить зависимости командой make install или запустить приложение через make start . Но остальные цели нужны только при первом разворачивании проекта и выполнять их нужно в определённой последовательности. Говоря языком мейкфайла, цель имеет пререквизиты:
Задачи будут выполняться только в указанной последовательности и только в случае успеха предыдущей задачи. Значит, можно добавить цель setup , чтобы объединить в себе все необходимые действия:
Теперь развернуть и запустить проект достаточно двумя командами:
Благодаря проделанной работе Makefile, команды проекта вместе с флагами сведены в Makefile. Он обеспечивает правильный порядок выполнения и не важно, какие при этом задействованы языки и технологии.
Продвинутое использование
Фальшивая цель
Использование make в проекте однажды может привести к появлению ошибки make: is up to date. , хотя всё написано правильно. Зачастую, её появление связано с наличием каталога или файла, совпадающего с именем цели. Например:
Как уже говорилось ранее, изначально make предназначалась для сборок из исходного кода. Поэтому она ищет каталог или файл с указанным именем, и пытается собрать из него проект. Чтобы изменить это поведение, необходимо в конце мейкфайла добавить .PHONY указатель на цель:
Последовательный запуск команд и игнорирование ошибок
Запуск команд можно производить по одной: make setup , make start , make test или указывать цепочкой через пробел: make setup start test . Последний способ работает как зависимость между задачами, но без описания её в мейкфайле. Сложности могут возникнуть, если одна из команд возвращает ошибку, которую нужно игнорировать. В примерах ранее такой командой было создание .env-файла при разворачивании проекта:
Самый простой (но не единственный) способ «заглушить» ошибку — это сделать логическое ИЛИ прямо в мейкфайле:
Добавлять такие хаки стоит с осторожностью, чтобы не «выстрелить себе в ногу» в более сложных случаях.
Переменные
Зачастую в команды подставляют параметры для конфигурации, указания путей, переменные окружения и make тоже позволяет этим управлять. Переменные можно прописать прямо в команде внутри мейкфайла и передавать их при вызове:
Переменные могут быть необязательными и содержать значение по умолчанию. Обычно их объявляют в начале мейкфайла.
Некоторые переменные в Makefile имеют названия отличные от системных. Например, $PWD называется $CURDIR в мейкфайле:
Заключение
В рамках данного гайда было рассказано об основных возможностях Makefile и утилиты make . Более плотное знакомство с данным инструментом откроет множество других его полезных возможностей: условия, циклы, подключение файлов. В компаниях, где имеется множество проектов, написанных разными командами в разное время, мейкфайл станет отличным подспорьем в стандартизации типовых команд: setup start test deploy . .
Возможность описывать в мейкфале последовательно многострочные команды позволяет использовать его как «универсальный клей» между менеджерами языков и другими утилитами. Широкая распространённость этого инструмента и общая простота позволяют внедрить его в свой проект достаточно легко, без необходимости доработок. Но мейкфайл может быть по-настоящему большим и сложным, это можно увидеть на примере реальных проектов:
Дополнительные материалы
- Руководство по современному Make — «выжимка» из документации на русском языке;
- Утилита make: полезный универсальный инструмент программиста — видео-версия данного гайда.
Мейкфайлы, использованные при составлении гайда:
Источник
Просто о make
Меня всегда привлекал минимализм. Идея о том, что одна вещь должна выполнять одну функцию, но при этом выполнять ее как можно лучше, вылилась в создание UNIX. И хотя UNIX давно уже нельзя назвать простой системой, да и минимализм в ней узреть не так то просто, ее можно считать наглядным примером количество- качественной трансформации множества простых и понятных вещей в одну весьма непростую и не прозрачную. В своем развитии make прошел примерно такой же путь: простота и ясность, с ростом масштабов, превратилась в жуткого монстра (вспомните свои ощущения, когда впервые открыли мэйкфайл).
Мое упорное игнорирование make в течении долгого времени, было обусловлено удобством используемых IDE, и нежеланием разбираться в этом ‘пережитке прошлого’ (по сути — ленью). Однако, все эти надоедливые кнопочки, менюшки ит.п. атрибуты всевозможных студий, заставили меня искать альтернативу тому методу работы, который я практиковал до сих пор. Нет, я не стал гуру make, но полученных мною знаний вполне достаточно для моих небольших проектов. Данная статья предназначена для тех, кто так же как и я еще совсем недавно, желают вырваться из уютного оконного рабства в аскетичный, но свободный мир шелла.
Make- основные сведения
make — утилита предназначенная для автоматизации преобразования файлов из одной формы в другую. Правила преобразования задаются в скрипте с именем Makefile, который должен находиться в корне рабочей директории проекта. Сам скрипт состоит из набора правил, которые в свою очередь описываются:
1) целями (то, что данное правило делает);
2) реквизитами (то, что необходимо для выполнения правила и получения целей);
3) командами (выполняющими данные преобразования).
В общем виде синтаксис makefile можно представить так:
То есть, правило make это ответы на три вопроса:
Несложно заметить что процессы трансляции и компиляции очень красиво ложатся на эту схему:
Простейший Makefile
Предположим, у нас имеется программа, состоящая всего из одного файла:
Для его компиляции достаточно очень простого мэйкфайла:
Данный Makefile состоит из одного правила, которое в свою очередь состоит из цели — «hello», реквизита — «main.c», и команды — «gcc -o hello main.c». Теперь, для компиляции достаточно дать команду make в рабочем каталоге. По умолчанию make станет выполнять самое первое правило, если цель выполнения не была явно указана при вызове:
Компиляция из множества исходников
Предположим, что у нас имеется программа, состоящая из 2 файлов:
main.c
Makefile, выполняющий компиляцию этой программы может выглядеть так:
Он вполне работоспособен, однако имеет один значительный недостаток: какой — раскроем далее.
Инкрементная компиляция
Представим, что наша программа состоит из десятка- другого исходных файлов. Мы вносим изменения в один из них, и хотим ее пересобрать. Использование подхода описанного в предыдущем примере приведет к тому, что все без исключения исходные файлы будут снова скомпилированы, что негативно скажется на времени перекомпиляции. Решение — разделить компиляцию на два этапа: этап трансляции и этап линковки.
Теперь, после изменения одного из исходных файлов, достаточно произвести его трансляцию и линковку всех объектных файлов. При этом мы пропускаем этап трансляции не затронутых изменениями реквизитов, что сокращает время компиляции в целом. Такой подход называется инкрементной компиляцией. Для ее поддержки make сопоставляет время изменения целей и их реквизитов (используя данные файловой системы), благодаря чему самостоятельно решает какие правила следует выполнить, а какие можно просто проигнорировать:
Попробуйте собрать этот проект. Для его сборки необходимо явно указать цель, т.е. дать команду make hello.
После- измените любой из исходных файлов и соберите его снова. Обратите внимание на то, что во время второй компиляции, транслироваться будет только измененный файл.
После запуска make попытается сразу получить цель hello, но для ее создания необходимы файлы main.o и hello.o, которых пока еще нет. Поэтому выполнение правила будет отложено и make станет искать правила, описывающие получение недостающих реквизитов. Как только все реквизиты будут получены, make вернется к выполнению отложенной цели. Отсюда следует, что make выполняет правила рекурсивно.
Фиктивные цели
На самом деле, в качестве make целей могут выступать не только реальные файлы. Все, кому приходилось собирать программы из исходных кодов должны быть знакомы с двумя стандартными в мире UNIX командами:
Командой make производят компиляцию программы, командой make install — установку. Такой подход весьма удобен, поскольку все необходимое для сборки и развертывания приложения в целевой системе включено в один файл (забудем на время о скрипте configure). Обратите внимание на то, что в первом случае мы не указываем цель, а во втором целью является вовсе не создание файла install, а процесс установки приложения в систему. Проделывать такие фокусы нам позволяют так называемые фиктивные (phony) цели. Вот краткий список стандартных целей:
- all — является стандартной целью по умолчанию. При вызове make ее можно явно не указывать.
- clean — очистить каталог от всех файлов полученных в результате компиляции.
- install — произвести инсталляцию
- uninstall — и деинсталляцию соответственно.
Для того чтобы make не искал файлы с такими именами, их следует определить в Makefile, при помощи директивы .PHONY. Далее показан пример Makefile с целями all, clean, install и uninstall:
Теперь мы можем собрать нашу программу, произвести ее инсталлцию/деинсталляцию, а так же очистить рабочий каталог, используя для этого стандартные make цели.
Обратите внимание на то, что в цели all не указаны команды; все что ей нужно — получить реквизит hello. Зная о рекурсивной природе make, не сложно предположить как будет работать этот скрипт. Так же следует обратить особое внимание на то, что если файл hello уже имеется (остался после предыдущей компиляции) и его реквизиты не были изменены, то команда make ничего не станет пересобирать. Это классические грабли make. Так например, изменив заголовочный файл, случайно не включенный в список реквизитов, можно получить долгие часы головной боли. Поэтому, чтобы гарантированно полностью пересобрать проект, нужно предварительно очистить рабочий каталог:
Для выполнения целей install/uninstall вам потребуются использовать sudo.
Переменные
Все те, кто знакомы с правилом DRY (Don’t repeat yourself), наверняка уже заметили неладное, а именно — наш Makefile содержит большое число повторяющихся фрагментов, что может привести к путанице при последующих попытках его расширить или изменить. В императивных языках для этих целей у нас имеются переменные и константы; make тоже располагает подобными средствами. Переменные в make представляют собой именованные строки и определяются очень просто:
Существует негласное правило, согласно которому следует именовать переменные в верхнем регистре, например:
Так мы определили список исходных файлов. Для использования значения переменной ее следует разименовать при помощи конструкции $( ); например так:
Ниже представлен мэйкфайл, использующий две переменные: TARGET — для определения имени целевой программы и PREFIX — для определения пути установки программы в систему.
Это уже посимпатичней. Думаю, теперь вышеприведенный пример для вас в особых комментариях не нуждается.
Автоматические переменные
Автоматические переменные предназначены для упрощения мейкфайлов, но на мой взгляд негативно сказываются на их читабельности. Как бы то ни было, я приведу здесь несколько наиболее часто используемых переменных, а что с ними делать (и делать ли вообще) решать вам:
Источник
Getting Started
Why do Makefiles exist?
Makefiles are used to help decide which parts of a large program need to be recompiled. In the vast majority of cases, C or C++ files are compiled. Other languages typically have their own tools that serve a similar purpose as Make. It can be used beyond programs too, when you need a series of instructions to run depending on what files have changed. This tutorial will focus on the C/C++ compilation use case.
Here’s an example dependency graph that you might build with Make. If any file’s dependencies changes, then the file will get recompiled:
What alternatives are there to Make?
Popular C/C++ alternative build systems are SCons, CMake, Bazel, and Ninja. Some code editors like Microsoft Visual Studio have their own built in build tools. For Java, there’s Ant, Maven, and Gradle. Other languages like Go and Rust have their own build tools.
Interpreted languages like Python, Ruby, and Javascript don’t require an analogue to Makefiles. The goal of Makefiles is to compile whatever files need to be compiled, based on what files have changed. But when files in interpreted languages change, nothing needs to get recompiled. When the program runs, the most recent version of the file is used.
Running the Examples
To run these examples, you’ll need a terminal and «make» installed. For each example, put the contents in a file called Makefile , and in that directory run the command make . Let’s start with the simplest of Makefiles:
Here is the output of running the above example:
That’s it! If you’re a bit confused, here’s a video that goes through these steps, along with describing the basic structure of Makefiles.
Makefile Syntax
A Makefile consists of a set of rules. A rule generally looks like this:
- The targets are file names, separated by spaces. Typically, there is only one per rule.
- The commands are a series of steps typically used to make the target(s). These need to start with a tab character, not spaces.
- The prerequisites are also file names, separated by spaces. These files need to exist before the commands for the target are run. These are also called dependencies
Beginner Examples
The following Makefile has three separate rules. When you run make blah in the terminal, it will build a program called blah in a series of steps:
- Make is given blah as the target, so it first searches for this target
- blah requires blah.o , so make searches for the blah.o target
- blah.o requires blah.c , so make searches for the blah.c target
- blah.c has no dependencies, so the echo command is run
- The cc -c command is then run, because all of the blah.o dependencies are finished
- The top cc command is run, because all the blah dependencies are finished
- That’s it: blah is a compiled c program
This makefile has a single target, called some_file . The default target is the first target, so in this case some_file will run.
This file will make some_file the first time, and the second time notice it’s already made, resulting in make: ‘some_file’ is up to date.
Here, the target some_file «depends» on other_file . When we run make , the default target ( some_file , since it’s first) will get called. It will first look at its list of dependencies, and if any of them are older, it will first run the targets for those dependencies, and then run itself. The second time this is run, neither target will run because both targets exist.
This will always run both targets, because some_file depends on other_file, which is never created.
clean is often used as a target that removes the output of other targets, but it is not a special word in make .
Variables
Variables can only be strings. Here’s an example of using them:
Reference variables using $<> or $()
Targets
The all target
Making multiple targets and you want all of them to run? Make an all target.
Multiple targets
When there are multiple targets for a rule, the commands will be run for each target
$@ is an automatic variable that contains the target name.
Automatic Variables and Wildcards
* Wildcard
Both * and % are called wildcards in Make, but they mean entirely different things. * searches your filesystem for matching filenames. I suggest that you always wrap it in the wildcard function, because otherwise you may fall into a common pitfall described below. It’s oddly unhelpful and I find it more confusing than useful.
* may be used in the target, prerequisites, or in the wildcard function.
Danger: * may not be directly used in a variable definitions
Danger: When * matches no files, it is left as it is (unless run in the wildcard function)
% Wildcard
% is really useful, but is somewhat confusing because of the variety of situations it can be used in.
- When used in «matching» mode, it matches one or more characters in a string. This match is called the stem.
- When used in «replacing» mode, it takes the stem that was matched and replaces that in a string.
- % is most often used in rule definitions and in some specific functions.
See these sections on examples of it being used:
Automatic Variables
There are many automatic variables, but often only a few show up:
Fancy Rules
Static Pattern Rules
Make loves c compilation. And every time it expresses its love, things get confusing. Here’s the syntax for a new type of rule called a static pattern:
The essence is that the given target is matched by the target-pattern (via a % wildcard). Whatever was matched is called the stem. The stem is then substituted into the prereq-pattern, to generate the target’s prereqs.
A typical use case is to compile .c files into .o files. Here’s the manual way:
Here’s the more efficient way, using a static pattern rule:
Static Pattern Rules and Filter
While I introduce functions later on, I’ll foreshadow what you can do with them. The filter function can be used in Static pattern rules to match the correct files. In this example, I made up the .raw and .result extensions.
Implicit Rules
Perhaps the most confusing part of make is the magic rules and variables that are made. Here’s a list of implicit rules:
- Compiling a C program: n.o is made automatically from n.c with a command of the form $(CC) -c $(CPPFLAGS) $(CFLAGS)
- Compiling a C++ program: n.o is made automatically from n.cc or n.cpp with a command of the form $(CXX) -c $(CPPFLAGS) $(CXXFLAGS)
- Linking a single object file: n is made automatically from n.o by running the command $(CC) $(LDFLAGS) n.o $(LOADLIBES) $(LDLIBS)
As such, the important variables used by implicit rules are:
- CC : Program for compiling C programs; default cc
- CXX : Program for compiling C++ programs; default G++
- CFLAGS : Extra flags to give to the C compiler
- CXXFLAGS : Extra flags to give to the C++ compiler
- CPPFLAGS : Extra flags to give to the C preprocessor
- LDFLAGS : Extra flags to give to compilers when they are supposed to invoke the linker
Pattern Rules
Pattern rules are often used but quite confusing. You can look at them as two ways:
- A way to define your own implicit rules
- A simpler form of static pattern rules
Let’s start with an example first:
Pattern rules contain a ‘%’ in the target. This ‘%’ matches any nonempty string, and the other characters match themselves. ‘%’ in a prerequisite of a pattern rule stands for the same stem that was matched by the ‘%’ in the target.
Here’s another example:
Double-Colon Rules
Double-Colon Rules are rarely used, but allow multiple rules to be defined for the same target. If these were single colons, a warning would be printed and only the second set of commands would run.
Commands and execution
Command Echoing/Silencing
Add an @ before a command to stop it from being printed
You can also run make with -s to add an @ before each line
Command Execution
Each command is run in a new shell (or at least the effect is as such)
Default Shell
The default shell is /bin/sh . You can change this by changing the variable SHELL:
Error handling with -k , -i , and —
Add -k when running make to continue running even in the face of errors. Helpful if you want to see all the errors of Make at once.
Add a — before a command to suppress the error
Add -i to make to have this happen for every command.
Interrupting or killing make
Note only: If you ctrl+c make, it will delete the newer targets it just made.
Recursive use of make
To recursively call a makefile, use the special $(MAKE) instead of make because it will pass the make flags for you and won’t itself be affected by them.
Use export for recursive make
The export directive takes a variable and makes it accessible to sub-make commands. In this example, cooly is exported such that the makefile in subdir can use it.
Note: export has the same syntax as sh, but they aren’t related (although similar in function)
You need to export variables to have them run in the shell as well.
.EXPORT_ALL_VARIABLES exports all variables for you.
Arguments to make
There’s a nice list of options that can be run from make. Check out —dry-run , —touch , —old-file .
You can have multiple targets to make, i.e. make clean run test runs the clean goal, then run , and then test .
Variables Pt. 2
Flavors and modification
There are two flavors of variables:
- recursive (use = ) — only looks for the variables when the command is used, not when it’s defined.
- simply expanded (use := ) — like normal imperative programming — only those defined so far get expanded
Simply expanded (using := ) allows you to append to a variable. Recursive definitions will give an infinite loop error.
?= only sets variables if they have not yet been set
Spaces at the end of a line are not stripped, but those at the start are. To make a variable with a single space, use $(nullstring)
An undefined variable is actually an empty string!
String Substitution is also a really common and useful way to modify variables. Also check out Text Functions and Filename Functions.
Command line arguments and override
You can override variables that come from the command line by using override . Here we ran make with make option_one=hi
List of commands and define
«define» is actually just a list of commands. It has nothing to do with being a function. Note here that it’s a bit different than having a semi-colon between commands, because each is run in a separate shell, as expected.
Target-specific variables
Variables can be assigned for specific targets
Pattern-specific variables
You can assign variables for specific target patterns
Conditional part of Makefiles
Conditional if/else
Check if a variable is empty
Check if a variable is defined
ifdef does not expand variable references; it just sees if something is defined at all
$(makeflags)
This example shows you how to test make flags with findstring and MAKEFLAGS . Run this example with make -i to see it print out the echo statement.
Functions
First Functions
Functions are mainly just for text processing. Call functions with $(fn, arguments) or $
If you want to replace spaces or commas, use variables
Do NOT include spaces in the arguments after the first. That will be seen as part of the string.
String Substitution
$(patsubst pattern,replacement,text) does the following:
«Finds whitespace-separated words in text that match pattern and replaces them with replacement. Here pattern may contain a ‘%’ which acts as a wildcard, matching any number of any characters within a word. If replacement also contains a ‘%’, the ‘%’ is replaced by the text that matched the ‘%’ in pattern. Only the first ‘%’ in the pattern and replacement is treated this way; any subsequent ‘%’ is unchanged.» (GNU docs)
The substitution reference $(text:pattern=replacement) is a shorthand for this.
There’s another shorthand that that replaces only suffixes: $(text:suffix=replacement) . No % wildcard is used here.
Note: don’t add extra spaces for this shorthand. It will be seen as a search or replacement term.
The foreach function
The foreach function looks like this: $(foreach var,list,text) . It converts one list of words (separated by spaces) to another. var is set to each word in list, and text is expanded for each word.
This appends an exclamation after each word:
The if function
if checks if the first argument is nonempty. If so runs the second argument, otherwise runs the third.
The call function
Make supports creating basic functions. You «define» the function just by creating a variable, but use the parameters $(0) , $(1) , etc. You then call the function with the special call function. The syntax is $(call variable,param,param) . $(0) is the variable, while $(1) , $(2) , etc. are the params.
The shell function
shell — This calls the shell, but it replaces newlines with spaces!
Other Features
Include Makefiles
The include directive tells make to read one or more other makefiles. It’s a line in the makefile makefile that looks like this:
This is particularly useful when you use compiler flags like -M that create Makefiles based on the source. For example, if some c files includes a header, that header will be added to a Makefile that’s written by gcc. I talk about this more in the Makefile Cookbook
The vpath Directive
Use vpath to specify where some set of prerequisites exist. The format is vpath
can have a % , which matches any zero or more characters.
You can also do this globallyish with the variable VPATH
Multiline
The backslash («\») character gives us the ability to use multiple lines when the commands are too long
.phony
Adding .PHONY to a target will prevent make from confusing the phony target with a file name. In this example, if the file clean is created, make clean will still be run. .PHONY is great to use, but I’ll skip it in the rest of the examples for simplicity.
.delete_on_error
The make tool will stop running a rule (and will propogate back to prerequisites) if a command returns a nonzero exit status.
DELETE_ON_ERROR will delete the target of a rule if the rule fails in this manner. This will happen for all targets, not just the one it is before like PHONY. It’s a good idea to always use this, even though make does not for historical reasons.
Makefile Cookbook
Let’s go through a really juicy Make example that works well for medium sized projects.
The neat thing about this makefile is it automatically determines dependencies for you. All you have to do is put your C/C++ files in the src/ folder.
Источник