22. Build systems and professional workflow

Make the build repeatable

A build is the set of steps that turns source files into a program. For one file, a compiler command may be enough. As soon as several files or tests are involved, people need a reliable way to repeat those steps without guessing.

1. Write down a compiler command that builds the program from its source files.
2. Repeat that command from a clean state and include useful warnings.
3. When commands become numerous, put them in a build system such as Make or CMake and document how to build, test, and run the project.

A successful build on your computer is not enough if it depends on an old executable or an undocumented local setting. The existing examples turn this simple workflow into a small project structure.

For small programs, a compiler command is enough. Larger projects benefit
from a build system such as Make, CMake, or the build tools native to the
platform.

A healthy workflow includes:

1. Choose and document the C standard and supported platforms.
2. Compile with warnings enabled; treat warnings seriously.
3. Separate modules and expose only necessary interfaces.
4. Keep builds repeatable and avoid relying on files from a previous build.
5. Run tests and static analysis automatically where possible.
6. Use version control to track changes.
7. Document how to build, test, and run the program.

Learn compiler options from the documentation for your compiler. Do not copy
flags blindly between GCC, Clang, and MSVC; their options differ.

Organizing a small project

A useful starting layout is:

project/
    include/
        vector.h
    src/
        main.c
        vector.c
    tests/
        test_vector.c
    README.md

The exact layout is a choice, not a C language rule. Keep source, public
headers, and tests easy to find. A build command should specify the standard,
warnings, and every source file needed to create the program. A build system
helps when projects have multiple targets, tests, generated files, or
platform-specific settings.

Version control gives you a history of changes and makes it easier to isolate
when a regression started. Make one coherent change at a time, build and test
it, and describe the reason for the change. The README should tell another
person how to build, run, and test the project, and identify any platform
requirements.

CC = gcc
CFLAGS = -std=c17 -Wall -Wextra -Wpedantic

app: src/main.c src/vector.c include/vector.h
	$(CC) $(CFLAGS) -Iinclude src/main.c src/vector.c -o app

clean:
	rm -f app

Save this as Makefile and run make or make clean where Make is
available. Make syntax and shell commands can vary by platform; a
cross-platform project may use CMake instead.

Checkpoint: Write down the exact command needed to rebuild one of your
programs from source in a clean folder.

---