Given app.c, inventory.c, inventory.h, and Makefile, explain and write the dependency rules needed so changing inventory.h recompiles both relevant object files before linking.
Requirements
Compile each .c file to its own .o
List headers in object prerequisites
Link only after every object is current
Show a hint
Write down the input contract and the failure cases before coding.
local runtime
RUNTIME OUTPUT
Use your C runtime locally, then compare with solution.c.
Use your local runtime, then review the reference solution
LEARN FROM THE SOLUTION
Why the solution works.
The header is a prerequisite of every translation unit that includes it. Explicit or generated dependencies prevent stale object files after an interface change; $^ supplies prerequisites to the linker and $< supplies the first prerequisite to each compile recipe.
What this exercise teaches
Translation units
Header dependencies
Reproducible builds
A PRACTICAL PLAN
Work through Audit a multi-file build with intent.
Translate the contract.Turn the requirements into a short checklist before editing your-solution.c.
Use the example as evidence.Predict the result for the supplied input, then add one boundary case such as an empty value, a limit, or unexpected input.
Review the implementation.Compare your choices against solution.c only after a real attempt.
EXERCISE FAQ
Before you move on.
What does “Audit a multi-file build” teach?
This advanced C exercise focuses on Translation units, Header dependencies, Reproducible builds. Its requirements define the exact behavior to implement before you write code.
How should I validate this C solution?
Write and compile the starter in your local C environment, exercise the example and edge cases, then compare your approach with solution.c.
When should I open the reference solution?
Attempt Audit a multi-file build first. Then open the read-only solution file to compare the contract, edge-case handling, and implementation choices—not simply to copy the final code.
