{"thread":{"id":"3966","subject":"Proposal: git-based dependency tracking build system","startedAt":"2006-04-26T00:13:42Z","lastAt":"2006-04-26T00:13:42Z","messageCount":1,"participants":["Matt McCutchen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"19129","messageId":"1146010422.2075.15.camel@mattlaptop","threadId":"3966","inReplyTo":null,"subject":"Proposal: git-based dependency tracking build system","fromName":"Matt McCutchen","fromEmail":"hashproduct@verizon.net","sentAt":"2006-04-26T00:13:42Z","receivedAt":"2006-04-26T00:13:42Z","isPatch":false,"sender":{"key":"hashproduct@verizon.net","avatar":null},"body":"Dear git people,\n\nI have been thinking for some time about how to write a foolproof\ngeneral-use build system that automatically tracks dependencies.  (Make\n+ depcomp is decent as long as source files aren't added/removed or\ngenerated often.  Cons is good but not general-purpose.)  I know there's\nbeen some work on tracing the compiler to see which files it actually\nopens.  Another possibility is to layer a FUSE filesystem over the build\ntree and note which files in the virtual filesystem are opened; this has\nthe advantage of missing most of the boring files (e.g. shared libraries\nthat make up the compiler).\n\nSo I was thinking, why not write a build system that uses git's\nexcellent hash-based object storage support to store the files in the\nvirtual build tree?  Hashing the files makes it easy to notice when a\nfile is rewritten with the same contents, meaning files that depend on\nit don't actually have to be rebuilt.  I also envision the build system\nautomatically marking generated files as git-ignored.\n\nThoughts?\n\n-- \nMatt McCutchen\nhashproduct@verizon.net\nhttp://hashproduct.metaesthetics.net/\n"}]}