The complexity of not lying to Makefiles

October 13, 2008

So, suppose that you are tired of lying to your Makefiles and want to fix the problem (in the abstract; you can't completely fix your Makefiles, because it's not fixable in anything like ordinary make). What does this take?

What you really need to capture is the state of the 'build inputs'. The build inputs are whatever goes in to creating the output, which is a lot more than just the source files involved; it also includes things like the test of the execution rule, the Makefile variables that go in to it, and even the programs that are run to create things.

(Actually, you don't care about the programs themselves so much as their 'interfaces' (in the programming language sense). You don't need to rebuild something just because the version of cp changed, because the old and the new version still have the same interface and thus will produce the same results.)

Capturing the state of build inputs is, in a sense, the easy bit; there is a lot of ways to capture and summarize the state of things. The difficult bit is figuring out just what is a build input. As my entry illustrates, you cannot rely on people to do this; it is too much work, especially if you are trying to really be thorough and truly solve the problem. Unfortunately, I don't think that anyone really knows how to do automated build analysis to capture this information, which leaves one somewhat out in the cold on the whole problem.

(My feeling is that automated analysis is only really practical in a captive build environment, but captive build environments rarely last for very long. Sooner or later they grow the ability to run external programs, and that's it for your ability to completely understand all build rules.)

Written on 13 October 2008.
« An irritating awk limitation: getting a range of fields
Improving initial ramdisks »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Oct 13 00:29:06 2008
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.