Make and Makefiles

GNU manual: https://www.gnu.org/software/make/manual/make.html

Makefile tutorial: https://makefiletutorial.com/

---

General info

Make is a build automation tool that automatically builds executable programs and libraries from source code by reading files called Makefiles. It determines which pieces of a program need to be recompiled and issues commands to recompile them.

A Makefile contains:

• Targets: What you want to build (files or actions)

• Dependencies: What's needed before building the target

• Commands: How to build the target

Basic syntax:

target: dependencies
	command

How to Use

1. Save as Makefile in your project root

2. Run commands like:

   make install      # Install dependencies
   make test         # Run tests
   make lint         # Check code quality
   make format       # Auto-format code
   make clean        # Clean up

Whatever target name you define becomes the command you run:

install:
	pip install -r requirements.txt

hello-world:
	echo "Hello!"

my-custom-task:
	python script.py

Then you run: make install, make hello-world, make my-custom-task

It is possible to run commands like this: make install hello-world my-custom-task

They're going to be run in the order you specify.

---

Important note: Make spawns a new shell for each line in a recipe by default.

Here's what happens:

target:
	cd /tmp
	pwd

This will not print /tmp — it will print your current directory. Each command runs in its own shell:

• Shell 1: cd /tmp (then exits)

• Shell 2: pwd (starts fresh in the original directory

Another example

. $(SRC_DIR)/.venv/bin/activate; pip install -Ur $(SRC_DIR)/requirements.txt

This line does two things:

1. Activates the virtual environment with . $(SRC_DIR)/.venv/bin/activate

2. Runs pip install in that activated environment

Why the semicolon is necessary:

By default, Make runs each line in a separate shell. If you wrote it like this instead:

. $(SRC_DIR)/.venv/bin/activate
pip install -Ur $(SRC_DIR)/requirements.txt

The activation would happen in one shell, then that shell would exit, and pip would run in a completely new shell where the virtual environment isn't activated. You'd end up installing packages to your system Python instead of the venv.

The semicolon keeps both commands in the same shell, so the pip install runs in the context of the activated virtual environment.

How to keep commands in the same shell

1. Use semicolons (as in the previous example):

   cd /tmp; pwd

1. Use && (stops if first command fails):

   cd /tmp && pwd

1. Use backslash continuation (makes it one logical line):

   cd /tmp && \
   	pwd

1. Use .ONESHELL: (special Make directive):

   .ONESHELL:
   target:
   	cd /tmp
   	pwd

This makes all lines in all recipes run in the same shell, but it's less commonly used because it changes behavior globally.

---

About the @ Symbol

Bash commands do NOT always begin with @. The @ is optional and controls visibility:

all:
    echo "This command will be echoed."
    @echo "This command will NOT be echoed."
    
# Another example, without @
test:
	echo "Running tests..."
	pytest
# Its output:
echo "Running tests..."
Running tests...
pytest
[pytest output]

# The same commands with @
test:
	@echo "Running tests..."
	@pytest
# Its output:
Running tests...
[pytest output]

• Without @ (default behavior)

  • Make prints both the command as it's being run and its output.

• With @ (suppresses command echo):

  • Only the output is shown, not the commands themselves.

Use @ for:

• Clean, user-friendly output

• Help messages

• Status messages

Don't use @ for:

• Debugging (you want to see what's running)

• Complex commands (transparency is helpful)

• CI/CD logs (full visibility preferred)

---

Variables

$() vs $$

The difference in notation.

$(VAR) = Make variable (defined in Makefile)

PYTHON := python3

test:
	$(PYTHON) -m pytest  # Expands to: python3 -m pytest

$$VAR = Shell variable (defined in shell commands)

test:
	export DB=mydb
	echo $$DB  # Expands to: mydb (in shell)

Key difference:

• $(...) → evaluated by Make

• $$... → evaluated by shell (the $ escapes to $ in shell)

Example showing both:

PYTHON := python3

run:
	for file in *.py; do \
		$(PYTHON) $$file; \
	done

• $(PYTHON) → Make replaces with python3

• $$file → Shell variable from the loop

---

Make variables

They're not quite the same as environment variables, but similar. Examples:

# Make variables
PYTHON := python3
UV := uv
PIP := pip3
VENV := venv
SRC_DIR := src

# Use bash for better scripting
SHELL := /bin/bash

# Name of the virtual environment directory
VENV_DIR := .venv
# Python interpreter from the virtual environment
PYTHON := $(VENV_DIR)/bin/python

# Use them with $(VARIABLE_NAME)
test:
    $(PYTHON) -m pytest $(SRC_DIR)

Note: := vs =

• := = immediate assignment (evaluates once)

• = = recursive assignment (evaluates each time used)

Most people use := for predictability.

---

Using environment variables

Load from an .env file

The most common method involves using the include directive within your Makefile to load variables from a .env file. This approach makes the variables available within the Makefile's scope.

# Make .env optional (won't error if file doesn't exist)
-include .env

# Or, if .env is mandatory, omit the hyphen:
include .env

# Example usage of a variable loaded from .env
build:
	echo "API Key: $(API_KEY)"
	# Your build commands using $(VARIABLE_NAME)

Variables loaded from .env are typically Makefile variables. To make them available as environment variables within the shell commands executed by your recipes, you need to export them.

Export Specific Variables

include .env

.PHONY: run
run:
	export DATABASE_URL=$(DATABASE_URL) && \
	export API_KEY=$(API_KEY) && \
	python app.py

Use Python-dotenv (load environment variables from a script)

.PHONY: run
run:
	python app.py  # Your Python code loads .env with python-dotenv

In your Python code:

from dotenv import load_dotenv
load_dotenv()  # Loads .env automatically

---

Automatic Variables: $< $@ $^

These are Make variables. They're shortcuts for dependencies and targets:

• $@ = target name (the thing being built)

• $< = first dependency

• $^ = all dependencies

• $* = stem in pattern rules

Examples:

# Example 1
report.html: data.csv
	python generate.py $< $@
# Becomes: python generate.py data.csv report.html

# Example 2
merged.csv: users.csv orders.csv products.csv
	python merge.py $^ $@
# Becomes: python merge.py users.csv orders.csv products.csv merged.csv

# Example 3
output.csv: input.csv transform.py config.yaml
	python $< transform.py  # Wrong! $< is input.csv, not transform.py
	python transform.py $< $@  # Correct!

Why use them?

• Less typing

• Works with pattern rules (explained below)

# Pattern rule - works for any file
data/processed/%.csv: data/raw/%.csv
	python clean.py $< $@

Pattern matching

If you run make data/processed/users.csv

• % matches users

• $< becomes data/raw/users.csv (input)

• $@ becomes data/processed/users.csv (output)

Command becomes:

python clean.py data/raw/users.csv data/processed/users.csv

How Python Receives It

Your Python script clean.py receives two command-line arguments:

# clean.py
import sys

# sys.argv[0] = 'clean.py'
# sys.argv[1] = 'data/raw/users.csv'      ← input file
# sys.argv[2] = 'data/processed/users.csv' ← output file

input_file = sys.argv[1]   # First argument after script name
output_file = sys.argv[2]  # Second argument

# Read from input, write to output
import pandas as pd
df = pd.read_csv(input_file)
df_clean = df.dropna()
df_clean.to_csv(output_file, index=False)

What happens:

1. Make expands: python clean.py data/raw/users.csv data/processed/users.csv

2. Shell executes the command

3. Python receives: sys.argv = ['clean.py', 'data/raw/users.csv', 'data/processed/users.csv']

4. Script reads from sys.argv[1], writes to sys.argv[2]

You may also use argparse.

---

?= - Assign only if not set

ENV ?= development  # Use 'development' if ENV not already set

# Equivalent to:
ifndef ENV
    ENV := development
endif

Usage:

make test              # ENV = development
make test ENV=prod     # ENV = prod (override)

---

Phony targets

.PHONY tells Make that a target doesn't produce a file with that name.

# Default target (runs when you just type 'make')
.PHONY: help
help:
	@echo "Available commands:"
	@echo "  make install    - Install dependencies"
	@echo "  make test       - Run tests"
	@echo "  make lint       - Run linters"
	@echo "  make format     - Format code"
	@echo "  make clean      - Remove generated files"
	@echo "  make run        - Run the application"

Why it matters:

Imagine you have this Makefile:

test:
	pytest

If someone creates a file named test in your directory, Make will see it and think "the target test already exists, nothing to do!" and won't run your command.

Solution:

.PHONY: test
test:
	pytest

Now Make knows test is a phony target (an action, not a file) and will always run it.

Common Phony Targets:

.PHONY: test clean install run help lint format deploy

These are all actions, not files, so they should be marked .PHONY. You can list them at the top of the Makefile and specify as .PHONY.

---

Automatic dependency resolution

Make's killer feature - automatic dependency resolution.

The Concept

When you specify a dependency, Make:

1. Checks if the dependency exists - if not, builds it first

2. Compares timestamps - only rebuilds if dependency is newer than target

3. Chains dependencies - recursively builds the entire tree

Examples:

When a target depends on another target (not a file):

.PHONY: deploy test build

# 'deploy' depends on 'test' and 'build' targets
deploy: test build
	echo "Deploying..."

test:
	pytest

build:
	docker build -t myapp .

What happens:

1. Run make deploy

2. Make first runs test target

3. Then runs build target

4. Finally runs deploy target

Key points:

• Enforces order - ensures test and build complete before deploy

• Always runs - because they're .PHONY (no timestamp checking)

• Chains actions - like "do this, then this, then that"

When a target depends on files:

# Code + data dependencies

makefileoutput.csv: input.csv transform.py config.yaml
	python transform.py

Which is great for file transformations (for example in ETL pipelines)

cleaned.parquet: raw.csv
	python clean.py $< $@

❌ Don't use dependencies for:

1. Always-run tasks (use .PHONY instead). Don't use always-run tasks for expensive file transformation tasks that are run even if files are unchanged.

.PHONY: test
test:
	pytest  # Always runs, doesn't check files

1. Dynamic dependencies (determined at runtime)

# Bad - files list changes at runtime
process: $(shell ls *.csv)  # Don't do 

---

The order of execution

Multiple Dependencies

# Output depends on multiple inputs
merged.csv: users.csv orders.csv products.csv merge.py
	python merge.py users.csv orders.csv products.csv merged.csv

Make runs this if ANY of these are newer than merged.csv:

• users.csv

• orders.csv

• products.csv

• merge.py

Parallel Dependencies

# These can run in parallel (no dependencies between them)
all: dataset1.csv dataset2.csv dataset3.csv

dataset1.csv: source1.json
	python process.py $< $@

dataset2.csv: source2.json
	python process.py $< $@

dataset3.csv: source3.json
	python process.py $< $@

Run with: make -j3 all (processes all 3 in parallel!)

---

Important flags in Make

Parallel Execution

Use multiple CPU cores to run specified targets.

make -j4          # Run 4 jobs in parallel
make -j           # Use all CPU cores (unlimited)
make -j8 test     # Run 'test' target with 8 parallel jobs
make -j       # ALL available cores (unlimited)
make -j$(nproc)           # Use all cores
make -j$(($(nproc) - 1))  # Leave one core free

When Parallel Helps

✅ Independent tasks (no dependencies between them)

# These can run in parallel
process-all: users.csv orders.csv products.csv

users.csv: raw_users.csv
	python process.py $< $@

orders.csv: raw_orders.csv
	python process.py $< $@

products.csv: raw_products.csv
	python process.py $< $@

make -j3 process-all

Dry Run / Debug

make -n           # Show commands without executing (dry run)
make --dry-run    # Same as -n

make -n pipeline  # See what 'make pipeline' would do

Ignore Errors

make -i           # Continue even if commands fail
make --ignore-errors

make -k           # Keep going (skip failed targets, continue others)
make --keep-going

Directory & File Options

make -C /path/to/dir    # Run make in different directory
make --directory=/path

make -f custom.mk       # Use different Makefile name
make --file=build.mk

Variable Override

make VAR=value          # Override Makefile variable
make ENV=production     # Set environment

make test PYTHON=python3.11  # Use different Python version

What-If

make -W file.csv pipeline  # Pretend file.csv was modified
make --what-if=file.csv

# See what would rebuild if file.csv changed

---

Using conditional directives

Summary Table

Directive	Purpose	Example
ifeq (a,b)	If equal	ifeq ($(ENV),prod)
ifneq (a,b)	If not equal	ifneq ($(DEBUG),)
ifdef VAR	If defined (non-empty)	ifdef API_KEY
ifndef VAR	If not defined (empty)	ifndef DATABASE_URL
else	Else clause	else
else ifeq	Else-if	else ifeq ($(OS),Linux)
endif	End conditional	endif

Data Engineering example:

.DEFAULT_GOAL := help

# Configuration
ENV ?= development
USE_DOCKER ?= false
PYTHON := python3

# OS Detection
UNAME_S := $(shell uname -s)
ifeq ($(UNAME_S),Linux)
    DETECTED_OS := Linux
else ifeq ($(UNAME_S),Darwin)
    DETECTED_OS := macOS
else
    DETECTED_OS := Windows
endif

# Environment-specific settings
ifeq ($(ENV),production)
    DB_HOST := prod-db.example.com
    LOG_LEVEL := ERROR
    PYTEST_FLAGS := -v --tb=short
else ifeq ($(ENV),staging)
    DB_HOST := staging-db.example.com
    LOG_LEVEL := WARNING
    PYTEST_FLAGS := -v
else
    DB_HOST := localhost
    LOG_LEVEL := DEBUG
    PYTEST_FLAGS := -v --pdb
endif

# Docker vs local
ifeq ($(USE_DOCKER),true)
    RUN_CMD := docker-compose exec -T pipeline
else
    RUN_CMD := 
endif

.PHONY: help
help:
	@echo "Environment: $(ENV) on $(DETECTED_OS)"
	@echo "Database: $(DB_HOST)"
	@echo "Docker: $(USE_DOCKER)"
	@echo ""
	@echo "Targets:"
	@echo "  make test        - Run tests"
	@echo "  make pipeline    - Run data pipeline"

.PHONY: check-env
check-env:
ifndef DATABASE_URL
	$(warning DATABASE_URL not set, using default: $(DB_HOST))
endif
ifdef CI
	@echo "Running in CI environment"
endif

.PHONY: test
test: check-env
	$(RUN_CMD) $(PYTHON) -m pytest $(PYTEST_FLAGS)

.PHONY: pipeline
pipeline: check-env
ifeq ($(USE_DOCKER),true)
	docker-compose up -d
	$(RUN_CMD) $(PYTHON) -m src.pipeline.run
	docker-compose down
else
	$(PYTHON) -m src.pipeline.run
endif

# Conditional target inclusion
ifeq ($(ENV),development)
.PHONY: lint
lint:
	$(PYTHON) -m ruff check src/
endif

---

Loops

Run shell loops inside recipes (the commands under targets):

.PHONY: process-all
process-all:
	for file in data/*.csv; do \
		echo "Processing $$file"; \
		python process.py $$file; \
	done

Key points:

• Must escape $ as $$ (so shell sees it, not Make)

• Use \ to continue lines

• Runs when the target executes

---

Targets that start with .

For Python, .PHONY and .DEFAULT_GOAL cover 90% of use cases.

.DEFAULT_GOAL-Set default target

.DEFAULT_GOAL := help

help:
	@echo "Run 'make test' to test"

test:
	pytest

When you just type make (without a target), it runs help instead of the first target.

.IGNORE - Continue on errors

.IGNORE: lint

lint:
	flake8 src/  # If this fails, Make continues anyway
	pylint src/

Normally Make stops on first error. .IGNORE makes it continue.

.EXPORT_ALL_VARIABLES - Export all Make variables

.EXPORT_ALL_VARIABLES:

PYTHON := python3
DATABASE := mydb

run:
	echo $$PYTHON     # Available as environment variable
	echo $$DATABASE   # Available as environment variable

.NOTPARALLEL - Disable parallel execution

.NOTPARALLEL:

# These will run sequentially even with make -j
test:
	pytest

lint:
	ruff check

---

Using Make with Docker

Note: you may specify image name and tag as a variable.

Basic Docker Commands in Make

.PHONY: docker-build docker-run docker-stop docker-clean

# Build Docker image
docker-build:
	docker build -t my-pipeline:latest .

# Run container
docker-run:
	docker run --rm -it my-pipeline:latest

# Stop all containers
docker-stop:
	docker stop $$(docker ps -q)

# Clean up
docker-clean:
	docker system prune -f

Docker Compose Integration

.PHONY: up down restart logs

# Start all services
up:
	docker-compose up -d

# Stop all services
down:
	docker-compose down

# Restart services
restart: down up

# View logs
logs:
	docker-compose logs -f

# Check service health
.PHONY: health
health:
	docker-compose ps

Real-World Data Engineering Example

.DEFAULT_GOAL := help
.PHONY: help

# Configuration
DOCKER_COMPOSE := docker-compose
DOCKER := docker
PROJECT_NAME := data-pipeline
IMAGE_NAME := $(PROJECT_NAME):latest

# Environment
ENV ?= development
COMPOSE_FILE := docker-compose.yml
ifeq ($(ENV),production)
    COMPOSE_FILE := docker-compose.prod.yml
endif

help:
	@echo "Docker + Data Pipeline Commands:"
	@echo ""
	@echo "Setup & Build:"
	@echo "  make build           - Build Docker images"
	@echo "  make rebuild         - Rebuild without cache"
	@echo ""
	@echo "Run Services:"
	@echo "  make up              - Start all services"
	@echo "  make down            - Stop all services"
	@echo "  make restart         - Restart services"
	@echo ""
	@echo "Development:"
	@echo "  make shell           - Open shell in container"
	@echo "  make logs            - View logs"
	@echo "  make test            - Run tests in container"
	@echo ""
	@echo "Pipeline:"
	@echo "  make pipeline        - Run data pipeline"
	@echo "  make extract         - Extract data"
	@echo "  make transform       - Transform data"
	@echo ""
	@echo "Database:"
	@echo "  make db-init         - Initialize database"
	@echo "  make db-migrate      - Run migrations"
	@echo "  make db-shell        - PostgreSQL shell"
	@echo ""
	@echo "Cleanup:"
	@echo "  make clean           - Remove containers"
	@echo "  make clean-all       - Remove everything"

# ============================================================================
# BUILD
# ============================================================================

.PHONY: build rebuild

build:
	@echo "Building Docker images..."
	$(DOCKER_COMPOSE) -f $(COMPOSE_FILE) build

rebuild:
	@echo "Rebuilding Docker images (no cache)..."
	$(DOCKER_COMPOSE) -f $(COMPOSE_FILE) build --no-cache

# ============================================================================
# RUN SERVICES
# ============================================================================

.PHONY: up down restart stop

up:
	@echo "Starting services..."
	$(DOCKER_COMPOSE) -f $(COMPOSE_FILE) up -d
	@echo "Waiting for services to be healthy..."
	@sleep 5
	$(MAKE) health

down:
	@echo "Stopping services..."
	$(DOCKER_COMPOSE) -f $(COMPOSE_FILE) down

restart: down up

stop:
	@echo "Stopping services (keeping volumes)..."
	$(DOCKER_COMPOSE) -f $(COMPOSE_FILE) stop

# ============================================================================
# DEVELOPMENT
# ============================================================================

.PHONY: shell logs ps health exec

# Open bash shell in main container
shell:
	$(DOCKER_COMPOSE) -f $(COMPOSE_FILE) exec pipeline bash

# Follow logs
logs:
	$(DOCKER_COMPOSE) -f $(COMPOSE_FILE) logs -f

# Show running containers
ps:
	$(DOCKER_COMPOSE) -f $(COMPOSE_FILE) ps

# Check health
health:
	@echo "Checking service health..."
	@$(DOCKER_COMPOSE) -f $(COMPOSE_FILE) ps
	@echo ""
	@echo "Database status:"
	@$(DOCKER_COMPOSE) -f $(COMPOSE_FILE) exec -T postgres pg_isready || echo "Database not ready"

# Execute command in container
# Usage: make exec CMD="python script.py"
exec:
	$(DOCKER_COMPOSE) -f $(COMPOSE_FILE) exec pipeline $(CMD)

# ============================================================================
# TESTING
# ============================================================================

.PHONY: test test-unit test-integration lint

test:
	@echo "Running all tests..."
	$(DOCKER_COMPOSE) -f $(COMPOSE_FILE) exec -T pipeline pytest tests/ -v

test-unit:
	@echo "Running unit tests..."
	$(DOCKER_COMPOSE) -f $(COMPOSE_FILE) exec -T pipeline pytest tests/unit/ -v

test-integration:
	@echo "Running integration tests..."
	$(DOCKER_COMPOSE) -f $(COMPOSE_FILE) exec -T pipeline pytest tests/integration/ -v

lint:
	$(DOCKER_COMPOSE) -f $(COMPOSE_FILE) exec -T pipeline ruff check src/

# ============================================================================
# DATA PIPELINE
# ============================================================================

.PHONY: pipeline extract transform load validate

pipeline:
	@echo "Running full pipeline..."
	$(DOCKER_COMPOSE) -f $(COMPOSE_FILE) exec -T pipeline python -m src.pipeline.run

extract:
	@echo "Extracting data..."
	$(DOCKER_COMPOSE) -f $(COMPOSE_FILE) exec -T pipeline python -m src.pipeline.extract

transform:
	@echo "Transforming data..."
	$(DOCKER_COMPOSE) -f $(COMPOSE_FILE) exec -T pipeline python -m src.pipeline.transform

load:
	@echo "Loading data..."
	$(DOCKER_COMPOSE) -f $(COMPOSE_FILE) exec -T pipeline python -m src.pipeline.load

validate:
	@echo "Validating data quality..."
	$(DOCKER_COMPOSE) -f $(COMPOSE_FILE) exec -T pipeline python -m src.pipeline.validate

# ============================================================================
# DATABASE
# ============================================================================

.PHONY: db-init db-migrate db-shell db-backup db-restore

db-init:
	@echo "Initializing database..."
	$(DOCKER_COMPOSE) -f $(COMPOSE_FILE) exec -T postgres psql -U postgres -c "CREATE DATABASE pipeline;"
	$(MAKE) db-migrate

db-migrate:
	@echo "Running migrations..."
	$(DOCKER_COMPOSE) -f $(COMPOSE_FILE) exec -T pipeline alembic upgrade head

db-shell:
	$(DOCKER_COMPOSE) -f $(COMPOSE_FILE) exec postgres psql -U postgres -d pipeline

db-backup:
	@echo "Backing up database..."
	$(DOCKER_COMPOSE) -f $(COMPOSE_FILE) exec -T postgres pg_dump -U postgres pipeline > backup_$(shell date +%Y%m%d_%H%M%S).sql

db-restore:
	@echo "Restoring database..."
	@read -p "Backup file: " file; \
	cat $$file | $(DOCKER_COMPOSE) -f $(COMPOSE_FILE) exec -T postgres psql -U postgres pipeline

# ============================================================================
# CLEANUP
# ============================================================================

.PHONY: clean clean-volumes clean-all prune

clean:
	@echo "Removing containers..."
	$(DOCKER_COMPOSE) -f $(COMPOSE_FILE) down

clean-volumes:
	@echo "Removing containers and volumes..."
	$(DOCKER_COMPOSE) -f $(COMPOSE_FILE) down -v

clean-all: clean-volumes
	@echo "Removing all Docker artifacts..."
	$(DOCKER) system prune -af --volumes
	@echo "Cleaned up!"

prune:
	@echo "Pruning unused Docker resources..."
	$(DOCKER) system prune -f

# ============================================================================
# MONITORING
# ============================================================================

.PHONY: stats inspect

stats:
	$(DOCKER) stats

inspect:
	@echo "Inspecting pipeline container..."
	$(DOCKER_COMPOSE) -f $(COMPOSE_FILE) exec pipeline env

# ============================================================================
# CI/CD
# ============================================================================

.PHONY: ci ci-test ci-lint

ci: build test lint
	@echo "✓ CI checks passed"

ci-test:
	$(DOCKER_COMPOSE) -f $(COMPOSE_FILE) run --rm pipeline pytest tests/ -v --cov=src

ci-lint:
	$(DOCKER_COMPOSE) -f $(COMPOSE_FILE) run --rm pipeline ruff check src/

Docker Network Management

.PHONY: network-create network-inspect network-clean

NETWORK_NAME := pipeline-network

network-create:
	docker network create $(NETWORK_NAME) || true

network-inspect:
	docker network inspect $(NETWORK_NAME)

network-clean:
	docker network rm $(NETWORK_NAME) || true

# Run with custom network
.PHONY: run-network

run-network: network-create
	docker run --rm \
		--network $(NETWORK_NAME) \
		--name pipeline \
		$(IMAGE_NAME)

---

Using Make with Python

While Make is traditionally used for compiled languages like C/C++, it's incredibly useful for Python projects to automate common tasks:

This article explains what you need to know: https://earthly.dev/blog/python-makefile/

---

Using Make with Golang

Golang has its own build automation tools such as:

• Mage: https://magefile.org/

• Task: https://taskfile.dev/docs/guide

• Just: https://github.com/casey/just

https://www.youtube.com/watch?v=XlobWOgcK7Y&pp=ygU1TWFrZWZpbGVzIGFuZCBHbzogU2ltcGxpZnkgYW5kIGF1dG9tYXRlIHlvdXIgd29ya2Zsb3c%3D

---