Debugging Configure

An anonymous reader writes "All too often, checking the README of a package yields only the none-too-specific "Build Instructions: Run configure, then run make." But what about when that doesn't work? In this article, the author discusses what to do when an automatic configuration script doesn't work -- and what you can do as a developer to keep failures to a minimum. After all, if your build process doesn't work, users are just as badly off as if your program doesn't work once it's built."

Comments

Ports

[cperciva]

Rather than attempting to include support for every architecture via autoconf, I think the BSD ports approach is far superior: Write code once, and have people put together their own sets of patches, makefile wrappers, et cetera to fit their own architecture.

For example, I wrote my binary patching tool on FreeBSD, but I don't recommend that people (even on FreeBSD) build it directly from the source tarball; instead, I advise people to use the ports tree, since that puts BSDiff into FreeBSD's packaging system. If someone running Gentoo wants to use BSDiff, they can install it from portage, which adds workarounds for gmake and linux breakage.

Most developers only have access to a couple platforms for testing their code. Rather than doing a poor job of supporting every platform, it makes much more sense to support one platform directly, and allow other people to step in and provide the necessary patches and packaging to support other platforms.