how does that fit into a build system? why would you require inspection of a running program to resolve build-time dependencies? and moreover, it's not like running a binary requires it to open all of the header and source files needed at build time, so how would you glean any useful data from it?

and what about systems that don't have strace, like BSD or OSX or solaris or windows? there's dtrace on those platforms (minus windows), which requires root, and requiring root access for dependency resolution isn't exactly a great idea.

It sounds like you don't strace your project, you strace the compilers and linkers to find out which headers and libraries they actually use. Then you know exactly which builds are possibly out of date at any point, even after a platform upgrade. Nobody bothers to note stuff like libc in their makefiles, a mistake which make can't help you avoid.

I think reading strace's output was a great experiment, but I don't think it's really that necessary. Most programs have some way of spitting out the dependencies, and some others follow pretty standard rules for file generation. For instance, ocaml optional interface files generate a .cmi file from a .mli file, and implementation files generate a .cmo file from a .ml file. However, if no .mli file exists, compiling the .ml file will also generate a .cmi file.

It can be a pain, but it's really not that hard to handle if your build system provides a way to abstract out build patterns.

FreeBSD has kernel DTrace (off by default), with userspace tracing on its way (in CURRENT). ktrace is a better option there, especially if you want to support other BSD systems as well.

I've used ktrace to help create minimal jail environments, quite handy: http://www.aagh.net/files/mkjail

So basically if you don't completely exercise your program while creating your build system, your build system won't know about all your dependencies?

Suddenly make is starting to seem pretty nice...

We're talking about build dependencies, not runtime dependencies. A build dependency is - by definition - one that is touched during the build process. strace exactly identifies that set.

This reminds me a lot of CDE Pack, can you explain how this is different?

If my program needs to be dynamically linked with, say, OpenSSL, but rarely actually uses it, how does introducing strace into this situation help?

i don't see how... if my code requires foo.h and bar.c, but those get compiled and linked into one executable. how will running that program expose that?

moreover, how can you run strace to figure out dependencies on a program that hasn't been built yet? how does it determine when new dependencies are added?

You strace the build steps (gcc bar.c), not the output program

you don't care about a dependencies of an non-existing target. you have to run it anyway. and once you run it at least once you will have the full set of its dependencies for the next time you run your build.