Fortran recipe

[Jeremy Huddleston Sequoia]

On Aug 28, 2013, at 18:06, Eric A. Borisch <eborisch at ieee.org> wrote:

> > 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.

Yes.  That is the first step.  The next is to fix issues which are causing some ports to fall back to llvm-g++ over clang++, but that isn't as pressing at the moment.

> >> 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.

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?

> 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.

Yes, I can understand that.  Let's try to come up with a way to solve this problem in a consistent way.

Unfortunately, in the not to distant future, clang++ will be the only valid C++ compiler for building a port that exposes/consumes API to/from other ports.

> Not sure what te 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.

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.

> 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?

--Jeremy


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4145 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20130828/ef3750d7/attachment.p7s>