Re:"I think that djb redo will turn out to be the Git of bui...
by prodigal_erik on Friday January 14, 2011 @06:12PM
(#2105811)
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.
Re:"I think that djb redo will turn out to be the Git of bui...
by erickt on Friday January 14, 2011 @07:12PM
(#2105946)
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.
Re:"I think that djb redo will turn out to be the Git of bui...
by Freaky on Friday January 14, 2011 @09:37PM
(#2106290)
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
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.