Fortran recipe

[Eric A. Borisch]

[Re-sent to list from correct address]

On Wed, Aug 28, 2013 at 4:50 PM, Jeremy Huddleston Sequoia
<jeremyhu at macports.org> wrote:
>
> On Aug 28, 2013, at 12:00, Eric A. Borisch <eborisch at macports.org> wrote:
>
>> Sorry for the blank email. Gmail interface whoops.
>>
>> So I come back from vacation and find the mpich port (I'm maintainer;
>> with openmaintainer) has been completely [1] revamped.
>>
>> The variants no longer do what I intended them to do. MPICH provides a
>> set of compiler wrappers (mpicc, mpicxx, etc.) that wrap compilers to
>> support MPI compilation as defined by the MPI standard. Previously the
>> variants (eg +gcc46) would wrap gcc-mp-4.6, g++-mp-4.6, etc. The
>> variants have been modified to now only wrap the fortran supplied from
>> the variant, and the CC and CXX are left to whatever MacPorts is
>> selecting as default on the system. Some of the variants (+clang and
>> friends) have been nuked completely.
>>
>> Now, I see from the thread (tl;dr) that there's been some thought put
>> in to what's going on here, and in other ports that use fortran from
>> gccXX, but I'd like to put mpich back to wrapping the requested
>> compiler suite (and not just fortran.)
>
> If that happens, then mpich cannot be used to build C++ code in other ports.  If that is something you're ok with, then fine... we can remove the mpich variant from other ports that would be using it for C++ code.

So the issue here is we need to nuke any g++-mp-NN code out of
existence if it's going was to be used as a dependency? Just making
sure I understand the concern.

>> Sooo. I'm considering reverting the changes made to the mpich
>> portgroup over the past week.
>
> Please do not do that without discussing here as that will just reintroduce the problems.

Well, that's why I'm here. :)

>
>> Given that the assumption at the
>> beginning of this thread - "If the port also has C and C++ sources,
>> then it would be preferable to leave configure.cc and configure.cxx
>> alone and just choose a fortran compiler" -- isn't correct in this
>> case, is there any reason _not_ to revert these changes?
>
> Why do you think that is not correct in this case?

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.

I believe there has been discussion about what mpich +gccNN should
mean in the past, and I'm not the only one with this expectation /
desire.

Not sure what the best way is to balance this desire with the other
(dependencies) concern. But making mpich +gcc47 where mpicc and mpicxx
call llvm-gcc or clang (depending on build platform), but mpif77 calls
gfortran-mp-47 is not what I would expect or want from the variant.

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.

Thanks,
  Eric