On Wed, Aug 28, 2013 at 9:14 PM, Jeremy Huddleston Sequoia <jerem...@macports.org> wrote: > > On Aug 28, 2013, at 18:06, Eric A. Borisch <ebori...@ieee.org> wrote: >> Because when _I_ install mpich +gcc47 and then call mpicc/mpicxx, I want to >> get gcc47 (c/c++) behind it. Perhaps I'm doing a hybrid model with OpenMP >> and can't use clang. > > Hmm... but isn't mpicc and mpicxx a wrapper? Why do you need to make that > decision at build time? Can't you let the user decide what C++ compiler > mpicxx uses at runtime?
Yes, it is a wrapper, but there are also the compiled libraries that actually supply the MPI functions. Yes, you can pass '-cc=XX' or use MPICH_CC, but the first reaction if something doesn't work right is to "try reconfiguring MPICH with the new compiler and installing MPICH in a separate location." (mpicc manpage) I take from that (and experience) that the best practice is to avoid this (crow-baring of compiler after the fact) approach unless it is unavoidable. I've been considering splitting out the different variants into (non-conflicting) subports; this would allow users to have different mpicc/compiler combinations installed at the same time. Perhaps this is also a solution to the problem here; the default / depended upon (mpich) based on <MP default C/C++>/gfortran and the separate versions (mpich_gcc44, mpich_clang33) being installed for outside-of-MP-scope development for those who want them. > I think the only time it would use llvm-gcc is on Xcode 4.0 and 4.1, which > aren't supported configurations. I think we officially just support 3.2.6 on > SL, 4.2 on SL, and 4.6 on Lion/ML. That means that the compilers we really > care about are gcc-4.2 and clang. >From the guide: llvm-gcc-4.2 with Xcode 4.0 and 4.1 on Mac OS X 10.6 and 10.7. Perhaps that doesn't mean supported, but it certainly is described / exists. (And happens to be what I'm sitting at.) >> If I'm the only one that wants it this way anymore, then I can always keep >> my own private version for myself, I suppose. > > No, if you want this, chances are someone else wants it as well... but I > would like to understand exactly *why* you want it. Are there performance > bugs with clang or the code it generates that I should be aware of? Are > there compatibility concerns? Did clang grow OpenMP support yet? There's no OpenMP in mpich, but can certainly show up in programs compiled with mpich. I also like to be able to build/test with the different compiler versions we also have installed and various linux systems. Granted, there are other differences, but OSX+gcc44 is "closer to" linux+gcc44 than OSX+clang is. I think it comes down to "I'm installing X (from MP) so I need this thing I've never met called MPICH that is required" or "I'm installing MPICH so I can write an MPI program, and I want to use *cc because of Z." Perhaps the best way to serve both ends is to create sub-ports as I mentioned above. Thanks, Eric _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
