Default configuration lets a framework, starter project, or shared internal tool provide a base set of build tasks without forcing every project to copy the same file.

If the project does not have its own build file, Build can fall back to the path supplied by --default.

vendor/bin/build --default ./config/build.default.ini

The default path may be either:

• a specific file such as ./config/build.default.ini
• a directory containing build.ini or build.json

¶How Build chooses between project and default config

Build checks for the project configuration first.

If a project configuration is found, that file is used. If no project configuration is found, Build tries the default path.

This makes defaults a good fit for frameworks and skeleton applications: projects can accept the shared configuration as-is, or add their own file when they need to customise it.

¶Overriding shared defaults

Once a project supplies its own build.ini or build.json, that project file becomes the active configuration.

This is useful when the shared default covers most projects, but one application needs a different entry point, a production-only optimisation, or an extra task for a particular directory.

Mode files continue to work in the usual way on top of whichever base configuration is active.

¶WebEngine

WebEngine exposes Build through gt build, so it can provide framework-level defaults while still allowing application projects to define their own configuration when required.

The Build repository is maintained separately, so the behaviour described here applies whether Build is used inside WebEngine or on its own.

---

From here, continue to see a JSON configuration example.