Wandering Thoughts archives


Why you do not want to patch your source code in place

Me on Twitter earlier today:

Protip: if your software's build process involves patching the source in place, sooner or later a sysadmin will hunt you down.

Perhaps it is not obvious why this is a bad idea, so let me go on at more length than a tweet allows.

The problem with patching in place is not so much that patching your source as part of building it is a bad idea in general (sometimes it's necessary), it is that patching in place makes it really hard to clean up after yourself if something goes wrong, especially if the patch is only partially applied. When you patch in place, 'make distclean' or the equivalent needs to revert the patch (and revert the right patch) and make sure it removes any lingering artifacts. Doing this reliably when something has gone wrong with the patching process is somewhere between challenging and almost impossible, and when your 'make distclean' fails all that people can do is delete the entire directory tree and re-extract it from your distribution tarball or VCS repo. This is very annoying, to put it one way.

(That patching in place creates spurious changes in VCS status output is another sign that it is a bad idea. In a DVCS this makes it very easy for people to commit or stash changes that they should not and thus to get their copy of the repo into a completely snarled state.)

When you do not patch in place, cleanup is simple and reliable: delete the build directory that holds the patched source. You do not have to worry about partially applied patches or keep careful track of new files; everything just vanishes. Sysadmins never have to 'clean up' by deleting everything and restarting from scratch. And everything stays clean and clear for people working from your version control system (for example, those who are trying out your latest development version).

This entry has been brought to you by someone who had to type 'svn revert -R .' a few too many times today.

(PS: once is too many times.)

Sidebar: why what RPM and Debian's package builder do is okay

Superficially, it looks like RPM (and I believe the Debian package manager) patch the source code of packages that they're building in place in this way, in that (eg) RPM directly applies whatever patches are specified on top of the source tree it extracted from your distribution tarball. The difference in what RPM does is that for RPM, the entire extracted source tree is simply a giant temporary build tree (and all of it will be removed to clean things up). The 'source' for RPM packages is the original distribution tarball and patch files, and these are never touched by the build process.

programming/InplacePatchingProblem written at 23:51:52; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.