4 ms·
Cache: http://webcache.googleusercontent.com/search?q=cache%3Ahttp%3A%2F%2Fwww.sharms.org%2Fblog%2F2010%2F12%2Fon-why-open-source-developers-run-mac-os-x%2F&ie=
by rwl 16y ago
Cache: http://webcache.googleusercontent.com/search?q=cache%3Ahttp%3A%2F%2Fwww.sharms.org%2Fblog%2F2010%2F12%2Fon-why-open-source-developers-run-mac-os-x%2F&ie=utf-8&oe=utf-8&aq=t http://webcache.googleusercontent.com/search?q=cache%3Ahttp%...
I'm not an "open source developer." But I do write code from time to time that I am happy to share with others. I run Debian on a desktop most of the time; essentially the only program I interact with outside of Emacs is a web browser. I do have a Macbook, though, that I use as a second computer when I'm away from home.
I am constantly frustrated by OS X.
The biggest reason is one of the `features' mentioned in the article: the `./configure && make && make install' routine seems to constantly break on OS X. This is a problem for me because much of the software I use (or try to play around with) doesn't specifically target OS X, so there generally aren't pre-compiled binaries available, and often the build instructions do not provide helpful hints for OS X users. I used to work in a lab that ran entirely on OS X. Compiling scientific libraries (e.g. SciPy) was frequently a recursive nightmare of trying to compile or otherwise install various dependencies (in SciPy's case, I remember the lack of gfortran being an issue).
Often, the problem has to do with missing libraries or figuring out how to set CFLAGS to cope with Apple's non-standard paths, both of which are headache enough. But sometimes the errors are just incomprehensible -- at least to someone without serious C knowledge -- and then I'm stuck.
Sometimes, Apple has done the hard work for you of properly configuring and installing popular Free programs (e.g. Emacs, Python) but the versions are Apple modified, can be difficult to get to work with outside libraries, and are often very old.
(I'm venting a bit here because I have been suffering from these sorts of problems fairly acutely in the last couple of days, but it really does seem to be an issue every time I want to use something on OS X: from Emacs to Python to Git to whatever else, something always seems to go wrong, even if it's not a dealbreaker.)
The bottom line is that OS X is a long way away, for me, from being an environment in which I can comfortably use all the software I want to without too much time lost down the rabbit hole of configuration. And I don't even spend most of my time programming! So I'd have to disagree with the sentiment of the article.
- younata 16y ago"the `./configure && make && make install' routine seems to constantly break on OS X." macports [1] is a great thing. I like it almost as much as I like freebsd's ports system (which is my favorite package system). [1] http://www.macports.org/ http://www.macports.org/
- rwl 16y agoAdmittedly, I have not taken the time to try MacPorts specifically. (This is probably due to the fact that the lab machine I worked on was polluted by various things installed via MacPorts, which seemed to mess with the autotools/configure process even further, if I was trying to compile something in ~/src. Left a bad taste in my mouth. But that's obviously not MacPorts' fault.) My experience is that these third-party package managers are great, until you want to make them work with software that doesn't come through the package system. A good test case, I think, would be this: how easy is it to install Python via [MacPorts|Fink|Homebrew|etc.] and then compile and run the latest SciPy (say, a bleeding-edge version from source control, not one from the package manager) against that Python? Can you speak to a case like this, or one of similar complexity?
- steveklabnik 16y agoGenerally, it just means that you need to get your prefix set up right. I've used MacPorts to install one dependency for something I was compiling by hand, and so I sort of did the opposite: I told MacPorts to install that particular package into the directory where I had hand-built the rest of them.
- oldpatricka 16y agoHmm. I've never used SciPy before but let's see if I can figure it out: $ brew install python pip gfortran # Fortran's for scipy... $ pip install numpy $ pip install svn+http://svn.scipy.org/svn/scipy/trunk/#egg=scipy http://svn.scipy.org/svn/scipy/trunk/#egg=scipy If you don't want to use the SVN version of SciPy, you can just use: $ pip install scipy Homebrew and pip are the first things I've ever used that made me not miss apt on debian.
- camperman 16y agoAmen to this. I've also been suffering from OSX compilation problems in the last few days and I have years of experience compiling packages from scratch. It's so bad that I'm about to switch back to using Ubuntu as a primary development machine. And macports has never worked properly for me on Snow Leopard. Fink is great for tools and libraries but the large source-based packages I'm interested in always break for some reason. I have failed to compile emacs, xemacs, Python, SDL, Irrlicht, gambit-c, Panda, Ogre and a whole bunch of others I've probably forgotten by now on OSX. All of them worked flawlessly on Ubuntu - ./configure && make && make install. Done. Compiling and installing on OSX - ugh. Yes xcode is lovely if you know how to drive it and are writing Objective C. For the rest of us, it's a wilderness.
- rue 16y agoIt really should not be that hard on 10.5 or 10.6. Try Homebrew? http://mxcl.github.com/homebrew http://mxcl.github.com/homebrew