Pants Full of Unix

… we’d be driving cars with 17 wheels, 8 transmissions, and 3 engines. This is especially true in the GNU crowd.

For reasons that will become apparent in a post I’ll make in a few days, I was simply trying to build ffmpeg out of the FreeBSD ports collection. Building individual ports immediately after updating one’s ports tree is always a pain in the ass, as they frequently (invariably, in the case of multimedia software) depend upon newer versions of various libraries and helper applications you already have installed, but FreeBSD’s ports handle this very gracefully with their deinstall and reinstall make(1) targets. That does mean that building something like this out of ports invariably involves five or six sessions under screen(1) for me as I descend those dependencies, but it does Just Work if you simply follow the recommendations.

After playing the usual game, however, for ffmpeg, I got this:

-(gr@stow:/usr/ports/multimedia/ffmpeg)---------------(Mon 2009-03-30 21:05.08)-
[0] % sudo make
[...]
Creating config.mak and config.h...
===>  Building for ffmpeg-2008.07.27_9
gmake: *** virtual memory exhausted.  Stop.
*** Error code 1

Stop in /usr/ports/multimedia/ffmpeg.

Well that’s a new one. And considering I’ve got 6 GB of addressable virtual memory on this system and top(1) indicates this didn’t even scratch at the 2 GB of that that’s physical upon a rerun, I’m highly dubious of the assertion.

Nope, apparently, “The FFmpeg build system *requires* GNU make 3.81, as you can read in the INSTALL file.” It’s obviously my fault for not kowtowing to your package’s documentation, rather presuming that you would have provided it in a reasonably usable state.

Why, pray tell, is GNU Make 3.81 required? It sure looks like it’s required because the targets include embedded and escaped regular expressions. Because, you know, that isn’t the sort of thing that we’ve all collectively decided (when we were adding maybe the seventh wheel to the car) to do with autoconf(1), so, sure, let’s push it further down the layers of abstraction in a way that’s completely backwards-incompatible. Sure, why not! I’ll just hang my ninth set of fuzzy dice (hey, D20s this time!) on my third rearview mirror and cruise right over that bridge to nowhere with you!

(Note that my ire here is finally triggered—I can take quite a lot, but this is just over the line—by Signor Sabatini’s attitude in response to a user query. I’m basically okay with the idea that he’s decided that his software needs a specific toolchain, even if I do think it’s a bullshit requirement, but the fact that he didn’t take the trouble at autoconf(1) time to warn the user of this requirement combined with the arrogance in responding publicly to a confused user is inexcusable. This is an error that is both easy to predict and easy to avert: all you have to do is check the installed version of GNU Make. Perhaps some blame also falls on the FreeBSD ports maintainer here, who could have made use of a standard hook to do that same job, but it’s extremely likely that he tested an upgrade to the package without reading INSTALL either after he’d happened to upgrade to GNU Make 3.81 for other reasons and never saw the failure. Also: I wasn’t graced with an archived email from him telling some other guy and, by logical extension, me that we were morons.)

If I’ve said it once (and I’ve lost count of how many times I’ve said this), I’ve said it a google (ha HA) times: what in the fucking hell is wrong with these people?