| 2 | | Working in scientific programming, with a focus on imaging and analysis. Started macport contributions in 2008. It began with {{{libpqxx}}}, the c++ API for {{{postgresql}}}. Also looking at developments for PostgreSQL ({{{postgresql83*}}}), Qt4 ({{{mac-qt4}}}), and the tools from www.kitware.com (incl. {{{vtk}}}, {{{vtk5}}}, and {{{InsightToolkit}}}). |
| | 2 | Working in scientific programming, with a focus on imaging and analysis. Started macport contributions in 2008. It began with {{{libpqxx}}}, the c++ API for PostgreSQL. Also looking at developments for PostgreSQL ({{{postgresql83*}}}), Qt4 ({{{mac-qt4}}}), and the tools from www.kitware.com (incl. {{{vtk}}}, {{{vtk5}}}, and {{{InsightToolkit}}}). |
| | 3 | |
| | 4 | After some experience in using Debian linux (incl. Ubuntu), the necessity for a streamlined, integrated, open-source distribution on mac OSX was clear to me. I started using fink, as it's based on a Debian system. However, I figured that OSX is a different beast and the opportunity to fully leverage it was probably going to happen through macports. I found that fink and macports do live happily together, so fink had to go. |
| | 5 | |
| | 6 | I tried running a few custom builds of several packages and found some peculiar linking behavior on OSX (mixtures of OSX frameworks, unix, and macport libraries were creeping into my builds, plus some rpath issues that were tricky to understand at first). It was soon clear that using macports was a better option than reinventing the wheel myself. I found the process of contributing to macports not only documented my own installation requirements, but also made those installations available to anyone who wants to use macports. I discovered that modifications to a macport could often get me the custom installation that I wanted. |
