Our single biggest holdup is our need for FORTRAN support.
Ditto. This is why I started worrying about this almost 10 years ago.
Clang - This would be nice, however I'm not really liking our FORTRAN options if we go this route. There's this "dragonEgg" thingy we might be able to use but it feels hackish and is labeled as experimental.
I'm still dubious of Clang, but maybe it's more mature now than I think is (when Lion was released, Macports was a mess for a couple of months because Clang was generating wrong code). That said, I haven't tried this yet.
GNU GCC: This is probably our best option. The question is, do we build it from source, download binaries, or get it through Fink/Mac Ports? There are various advantages/disadvantages to each of these. Paul, you've been using GNU GCC (as opposed to Apple GCC) for sometime now. I know you've answered this before but what are your thoughts challenges with this? Have you ever messed with the Fortran piece?
First, G95 is horrible. I had a lot of problems with it. gfortran has been an excellent Fortran 77/90 compiler since 4.4. And is very close to fully functional 2003 as of 4.7.
I tried Fink a long time ago and ultimately abandoned it because it was hard to uninstall things and it liked to put stuff in places like /usr which annoyed me very much. It's been a long time since I've used it (6 years I think), so it very well could have changed.
I use MacPorts for everything *but* the compilers/compiled libraries I use. In particular, I MacPorts to supply autotools, octave, doxygen, coreutils (GNU instead of BSD utilities), python and all python modules (e.g. numpy, matplotlib), scons, etc. This works very very well for me. The only caveat, as mentioned above, when the OS changes, Apple tends to pull the rug out from under you on the compiler and it can take come time for MacPorts to catch up.
Some folks around here also use MacPorts for supplying the compiler, MPI stack, HDF5, and some others. If you're *very* careful, this can work. The problem is that it's *really* easy to have the compiler you're using and the compiler used to compile a library not match up. For example, the maintainer of the boost port might decide to switch to a different compiler port and it's practically invisible to you. Folks had/have a lot of linking trouble because of this. I have not tried using just the MacPorts compiler and building my own stuff, but, again, you can run into linker problems because, for example, if you use boost, depending on where /opt/local/lib gets pulled in on the linker line (for the compiler libraries), you could end up pulling in boost from macports. So, if you leverage MacPorts for a lot of stuff, this can easily happen. If you keep your MacPorts install lean, you'll probably be able to avoid these issues.
Given the above discussion, I've been building from scratch for a long time. Another perk is you can try out new compilers early on and anticipate problems that might crop up. Building from scratch is, really, very simple and can be handled completely with script(s). You will need GMP, MPFR (and MPC for gcc >= 4.5), which I also tend to build. This has worked very well for me. However, as of OS X Lion, there have been a couple of problems that I haven't been able to figure out and that have persisted into Mountain Lion which you will want to consider. libMesh miscellaneous_ex6 outright fails with an ugly stack trace that goes all the way to a linker function. I have also not been able to get TBB to work with libMesh successfully (segfaults) on my laptop (works fine on Linux workstation). However, every other code I compile and use has run just fine, in parallel, etc including Fortran codes. However, I'm still nervous because I haven't been able to sort out the above couple of issues.