Adds pip, homebrew and builtin satisfier for initial OS X support.

[FlorianFranzen]

The 'builtin' satisfier only supports OS X at the moment. If there is not any other OS that ships with built-in libraries, one could probably just rename the module to a more OS X specific name.

Everything was tested on OS X Mavericks (10.9) successful.

UHD and gnuradio still have some minor build issues on OS X, especially if they are not compiled with GCC, but these are things that have to be fixed upstream.

[osh]

this is an awesome, commit thanks for putting all this together - I have a couple comments though
Is "builtin" mac-ports? It would be nice to name this "macports" or something more explicit so as not to confuse users of other operating systems - Also I'm not sure why it does not appear in the satisfy order? When using ubuntu or redhat I would want to completely disable to macports staisfier. Also - adding pip is interesting, as long as people are using the system-python that should be fine, I'm curious if any issues would come up when building our own version of python inside the target prefix -- I'm happy to pull that in and start testing to see if anything comes up though.
-Tim

[FlorianFranzen]

No, builtin is not mac-ports.

Mac OS X by default does not come with a unix style package manager. Therefore projects like fink, mac-ports and homebrew exist. In difference to most Unix package managers, packages are installed to a different prefix, like /usr/local or /opt/local, i.e. they are installed next to all the binaries and libraries that already come with OS X (or XCode and other rare exceptions) which reside in /usr.

The binaries and libraries that come with OS X and XCode are therefore 'built-in'. Since I am not sure if any other operation system comes with built in binaries and libraries, I named the satisfier builtin, even though, right now, it only know about OS X and what it comes with.

[osh]

these should be called osxbuiltin or something - they are osx specific and can not just be called "builtin" for the sake of linux users. There should probably be some kind of marking in any recipe that is satisfied by this satisfier - i really want to avoid having package names hard coded into the depths of any satisfier's python implementation.

[osh]

I think a reasonable syntax might be like in "gcc.lwr" you could add a line that says "osxbuiltin: true" or something, and then the osxbuilting satisfier could see that that as ok - if and only if osxbuiltin was in the satisfy order - the same way other satisfiers work

[osh]

closing due to inactivity

[FlorianFranzen]

That is probably a good idea. Without a patch stage in pybombs before building, getting gnuradio to build cross platform would require a lot of upstream merges. I started the process of getting some of the bugs fixed, but it is just a cumbersome task and nobody seems to care too much, so response times are long. Apparently having a clean cross platform build is not one of the main gnuradio mission goals.

Therefore just building gnuradio with homebrew alone is now my preferred way and it works quite well. If I ever get some of the upstream build system bugs fixed, I will make sure it is merged into homebrew/science tap so evertone can use it.

Also, if you really need gnuradio these days on OS X, just install macports: They have a really good and active (paid?) package maintainer for gnuradio, so it should works right out of the box.