From project files to a runnable build
An Elements project brings together source files, resources, references, and build settings. Turning those inputs into an app or library takes a series of steps. EBuild reads the project, determines which tasks the target needs, and runs them in the right order. Invoking the Elements compiler is one of those tasks.
Fire, Water, Earth, Visual Studio integration, and the command-line tools use the same project and build system. You can build from your IDE while developing, then run ebuild from a terminal or a CI script using the same project settings.
What happens during a build
Before compilation, EBuild determines which files and settings apply to the selected target. It selects the platform SDK version and locates the references the compiler needs, including platform libraries, third-party components, and packages.
After compilation, the next steps depend on the target. Cocoa and Island builds can require a linker to combine native object files. Resources may need to be converted or processed. Android, macOS, and iOS apps need their compiled code, resources, and metadata assembled into the platform’s app package or bundle. EBuild also handles signing when the target and build settings call for it.
On incremental builds, EBuild tracks which inputs have changed and skips tasks whose results are still current. It gathers errors and warnings from the full build, so missing references, compiler errors, and failures in linking or packaging are reported through the same build log.
Why It Matters
EBuild keeps the practical parts of daily development lined up, from local debug builds to CI automation.
Shared with Fire
Mac-native builds in Fire.
Shared with Water
Windows development in Water.
Shared with Earth
Builds from Earth on Linux.
Shared with CLI
Command-line builds and automation use the same definitions instead of a second parallel setup.