I haven't used Linux for a long time now. I remember with mixed feelings compiling programs: partially, the satisfaction of having a piece of software exactly tuned for your machine, and partially the pain of stashing up files somewhere in the system without being exactly aware of how to get rid of them later on.
Fast forward 10 years (did I say 10? Great Scott!), I'm sitting here at my shiny MacBook Pro and thinking "Heck, I'd really need this or that program/library/whatnot".
Now, would I be happy to pile up files randomly in OS X? Not exactly. Would I be happy to create a ~/local folder where to save the binaries? Good luck with that if you need to link to a library. Here's where tools like fink or MacPorts come in handy. However, for a reason or another, neither of those never quite hit the spot for me.
The one that did hit the spot was Homebrew. I'm not exactly sure why. Probably because it's quite easy to use (not that the others aren't) but allows you to customize quite a lot of your installation (brew install --interactive package). Also, it's very easy to compile a package that isn't included in the distribution, but registering it within Homebrew so that it's easy to remove or update later on. Once you do that, you can also contribute to Homebrew itself if you're so inclined, that way you'll save others from going through the same pain you've suffered (I haven't gone that far yet, possibly because what I compiled so far required a few tricks that would take me too much work to recreate in an automated script).
So, here are a couple of tricks I learnt that weren't obvious from the documentation. Say you want to compile some package that comes with Homebrew, but for some reason you desperately want it to be tuned for your CPU, or you want to compile it with/without a certain feature which Homebrew doesn't/does include by default. The way to go is:
brew install --interactive package
At this point you're on your own to go through the usual configure; make; make install routine. Something that helps you in this is brew diy, which can be used to tell configure where to send your compiled binaries (it sets the --prefix option to configure). The command would be something like this:
./configure $(brew diy)
although of course you have to add your own options to that.
The other very useful trick is compiling packages that aren't included in Homebrew, registering them in Homebrew so that you can easily delete them later on. Say you want to install painfulcompilation 1.0. You decompressed the .tar.gz and now your terminal is on the folder painfulcompilation-1.0. This is what you need to do:
./configure $(brew diy)
make
make install
brew link painfulcompilation
and magically, painfulcompilation is installed in what is know as the Cellar, and all the binaries are linked to /usr/local/. How cool is that?
Naturally not everything is perfect. Something quite crucial is to make sure that your user has permissions to write in /usr/local otherwise you're going to have a bad time (although fortunately this type of error is quite easy to track down).
The good thing in all this is that it allows for all the dirtiest tricks that get something compiled. For example, I was trying to install the pfstools on my laptop (they're a set of tools to operate on HDR images, if you're interested). Funny thing, clang would compile most of them but then would fail in one of the tone mapping operators (Fattal's if you're interested) because it doesn't support OpenMP. On the other hand, llvm-gcc supports OpenMP but would give an error on another tone mapping operator. So I used two compilers to compile the whole package, by calling ./configure a second time after I got the first error. So that is the kind of stuff that you can get away with using homebrew.
