When automating 4D builds with Build4D and Tool4D, one of the most frustrating experiences is when build processes appear to run but fail silently. Generic error messages like "Build failed" or complete silence often occur when:

- Building through CI/CD pipelines without access to the 4D interface
- Running Tool4D in headless mode

Without proper logging, debugging becomes a time-consuming trial-and-error process.

To overcome these situations, add strategic `LOG EVENT` statements throughout build methods to create a detailed build log. Tool4D captures these log events and outputs them to the terminal or to a log file.

`LOG EVENT(Into system standard outputs; ...)` writes directly to the standard output stream that Tool4D captures. When Tool4D runs with output redirection (like `> build_output.txt`), all these log statements end up in the output file, providing a complete picture of what happened during the build.

Here's an example of how to implement it:

//.. // At the start of the build method LOG EVENT(Into system standard outputs; "Starting Build Process") // Before each major step LOG EVENT(Into system standard outputs ; "Building client application...") $clientResult := buildClient() // Log the actual results LOG EVENT(Into system standard outputs; "Client build result: " + JSON Stringify($clientResult)) // Check for success/failure If ($clientResult.success)    LOG EVENT(Into system standard outputs; "Client build succeeded")    LOG EVENT(Into system standard outputs; "Building server application...")    $serverResult := buildServer()    LOG EVENT(Into system standard outputs; "Server build result: " + JSON Stringify($serverResult)) Else    LOG EVENT(Into system standard outputs; "Client build failed - aborting server build") End if

The difference between silent failure and proper logging is now clear

• Without LOG EVENT (silent failure)



• With LOG EVENT (detailed output)