… 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?
3 Comments
Your description amused me thoroughly. Maybe I’m just a sucker for D20 humor.
I recently had a similar experience in the IRC channel for WoW mod development, in which I was more or less publicly mocked, first for not knowing who the person answering my question was (and what I’m sure thoroughly amazing mods he’s made), and second for daring to use an XML definition file as per the official documentation (developers have figured out a hacky way around this that is supposedly more memory efficient).
I read this just for pure chance, since I don’t want to make go completely injustified and offensive rants against the project to which I feel honourated to partecipate and against my very name, I’ll reply to this.
I can’t find nothing wrong about my one-line reply, it was plain informative, I really can’t see nothing offensive about that, I even bothered to quote the INSTALL file, while you could have easily found the solution to your problem with a quick Google search or in the archive.
I’ll even bother to mention that I myself spent *several* frustrating hours trying to fix the Makefile and make the misbehavior of make < 3.80 recognized, before to resign and realize that trying to fix compatibility with bogus/broken random versions of make was just vain and unreliable anyway, so we *wisely* decided to only support that version and even bothered to *clearly document that* in the INSTALL file.
As for the autoconf hell, I can’t see why it’s mentioned at all as in FFmpeg it’s refrained, a nice portable lovely hand-crafted configure script is delivered instead.
Also consider that free software projects are most of the time a volunteer-based effort, even if you’re not supposed to be grateful, at least you should take into account the time and effort that is delivered to you for free before to spit completely unfounded critics.
Regards.
Stefano, I don’t know whether you bothered to request notification on response to this (and I’d check, except that I’ve better things to do than dig through Wordpress’s documentation to learn how I’d do that… which bears upon my original point here, of which your software was just the example providing the final catalyst), but since you stumbled upon this absent any knowledge that I existed, I figure it’s only fair to (belatedly, for which I apologize) approve your comment and spend a few moments responding to it.
I didn’t do a very good job of saying it, because I was (perhaps obviously) frustrated at the time, but I don’t mean to imply that all of the blame here falls upon you. Regardless of what features they choose to provide with whatever version level, the degree to which GNU’s software in general and their buildchain specifically are a painfully and rapidly moving target is precisely the sort of bullshit against which I was reacting here. You, as a developer, should not need to waste your time jumping through hoops to figure out how to make their tool build your software properly: it should Just Work… BUT, your end consumer, should open source software ever actually be useful to people who are not systems administrators by profession, should NEVER see an error message like this.
Some small degree of fault also lies with whoever was then maintaining the FreeBSD port for you package. There exists a completely functional structure within that API to assert that version 3.81 of GNU’s make was required for the package to build, and it’s that person’s fault (by virtue of oversight, I have to presume: she or he had probably already upgraded their own GNU buildchain and didn’t even see the error) for not specifying the dependency. You’re correct that you did all that you could by noting the issue in the INSTALL file… but in the real user world, I, not the maintainer of any FreeBSD package let alone this one, wasn’t stepping through every piece of software involved, I was just trying to upgrade (if memory serves) MPlayer, and FreeBSD’s package dependency tree crapped out with a meaningless (and incorrect) error message generated when it tried to build the software you wrote. Yes, I could and did ask Google for the answer, but it’s a functional failure of the entire system that I needed to.
I do take your point about open source software’s being a volunteer effort. Having previously contributed to the NetBSD project (not just monetarily, but also in kind) and currently doing the same sort of thing morally, if very differently in action, for the US Bartenders’ Guild, I’m on that same page with you. The fact remains, however, that a goal of open source software should be usability for real people, just as a goal for the events that the USBG organizes for bartenders oughtn’t be to give bartenders free booze, but to help them serve their customers.
Problems like this are exactly the sort of thing that steer those potential users (and potential contributors, whether monetarily or by volunteering their own time) away from OSS and back to commercial software. That, incidentally, is the Correct response to the rhetorical question with which I concluded the original post.
Post a Comment