darwinbuild currently uses DYLD_INSERT_LIBRARIES/ DYLD_FORCE_FLAT_NAMESPACE with the "darwintrace.dylib" to log open(2) and execve(2) system calls, for use in dependency analysis. This is great for determining *what* is used during a project build, but not "how" or "why" or "when" Some experimental ideas I'm planning on taking a look at: 1) Full logging of execve(2) arguments 2) shell-escaping the execve(2) arguments so you can copy-paste compiler invocations and such. 3) build a shell script to replay a build, to the extent that this is possible with shell commands. During a build, there is some computation/processing that would not be captured here. 4) synthesize shell commands for some system calls, like mkdir(2) 5) translating volfs paths to normal paths, for better logging of Carbon File Manager clients. 6) tracking system calls to a pid and process name, so you can filter on what a particular process does/did. 7) refactoring compiler invocations, etc., to take common sets of arguments and store them in a shell variable. 8) Some more semantic interpretation of files and paths based on extension, magic, etc. The overall goal is to attack the Darwin self-hosting issue from the tools end, instead of emulating Xcode in a top-down approach. Accomplishing these sets of tasks would get you either some straightforward shell scripts, or possibly makefiles. There should also be intelligent diffing of the end results so you can see what changed between software updates (like a new file was added, and this is immediately obvious). Some of these steps can be done independently and non-sequentially. If you're interested in some of these issues, and want to coordinate, let me know. Shantonu