On Thu, Jul 25, 2013 at 9:31 PM, Sean Farley <s...@macports.org> wrote: > > ebori...@macports.org writes: > >> On Thursday, July 25, 2013, Sean Farley wrote: >> >>> >>> ebori...@ieee.org <javascript:;> writes: >>> >>> > On Thursday, July 25, 2013, Sean Farley wrote: >>> >> >>> >> But really, we're at the whim of what the macports community whats to do >>> >> in this situation. Since my Ph.D is riding on getting a working mpi + >>> >> fortran, I'd very much like to iron out these issues and get the ports >>> >> chugging along! >>> >> >>> > >>> > Does mpich +gccXX not get you to working fortran and MPI? >>> > >>> > I'll try to read through some of this thread later, but just looking for >>> > clarification on that point. >>> >>> Again, the issue is when using libraries dependent on mpi and >>> exacerbated on dependents of those dependents. This usually results in >>> breakage with the inability to specify which compiler to use in the n-th >>> dependent. >>> >> >> Again, I haven't scoured the whole thread, but would making sub-ports >> rather than variants for the different compilers help? The >> dependent's +gcc44+mpich could require the mpich-gcc44 package, for example. > > Not really. It just changes the name to the same problem.
Except for the fact that you can *depend* on the package (user gets warnings if they try to install it) but MP will happily let the user change the variants without warning to the (active) dependents of that package. I personally swap back and forth between variants of mpich when I'm testing my own MPI code (why, oh why, doesn't clang have OpenMP support yet?) Hopefully rev-upgrade will catch that something has (potentially) gone south, but it won't likely be able to rebuild things back to their initial state without some hand-holding. We could setup the different packages to avoid naming conflicts (much like gcc44, gcc45) so multiple versions could be installed side-by-side. An mpich_select could even be put together to redirect mpicc -> mpicc-gccNN. I'm not saying it's necessarily the right idea, I'm just throwing it out there. - Eric -- Eric A. Borisch _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
