Request for comments: mpi and using multiple compilers

[Sean Farley]

ryandesign at macports.org writes:

> On Jul 20, 2013, at 18:28, Sean Farley wrote:
>
>> I'm looking for comments and feedback for two new port groups:
>> multiple compilers [1] and mpi [2]. My goal is to unify all the gcc4X
>> variants and mpich / openmpi variants scattered throughout the port
>> tree.
>> 
>> Here's a summary of the port groups:
>> 
>> - provide variants for all compilers
>
> I'm still pretty uneasy about this. Ports currently do a wide variety of things in their gcc variants, from setting variables and configure args, to a difference between whether the port builds with that gcc port's gcc and g++ compilers as well, or only with its fortran compiler. How will you accommodate all the variations?

If the port wants to do something specialized then it could simply put
the special code in an if-block:

if {[variant_isset gcc46]} {
  ...
}

My view is that +gccXY should use gcc, g++, gfortran as the compilers,
hence, I've provided +gfortran and +g95 to provide only the fortran
compilers.

But for now, I just want these port groups for a small number of ports;
mainly, petsc, sundials, mumps, and fenics.

> Also, I think it needs to be up to each individual port to specify which gcc variants to create. Not all ports are compatible with all gcc versions. Or perhaps I just have a unique perspective on that due to pdftk, which has some severe problems in that regard. Or rather, it's that pdftk doesn't use fortran, it uses java, and perhaps it's gcc's java compiler that has severe problems. For example, gcc46 doesn't contain the java compiler at all because we could never get it to work with that version. gcc43 doesn't have the java compiler on Tiger. If other ports generally don't care, then maybe it's not important, and the portgroup can provide all gcc variants, and pdftk can simply continue to create variants manually and not use the portgroup.

Yeah, I've completely punted on the java issue. Ideally, it could follow
the same code I've written for the fortran case. Looking at pdftk
specifically, you could change the variants to be an if-block to do all
the patching and special case stuff.

>> (should there be a way to blacklist?)
>
> Setting compiler.blacklist as needed seems sufficient.

What about your above example of pdftk? Would the portfile author have
to put an error in it?

if {[variant_isset +gcc46]} {
   return -code error "Not supported"
}

Having, 'multiplecompilers.blacklist gcc43 gcc46' might be easier?

>> - provide mpi variants e.g. netcdf [3]
>
> I have no opinion on this.
>
>
>> * Should there be a default compiler (i.e. +clang)? Currently, I have
>> this implemented but maybe it could be removed.
>
> I can't think of a reason why there should be a clang variant or variants. If a port cannot be compiled with gcc or llvm-gcc-4.2 or the old version of clang on Snow Leopard, then depend on the newest stable version on those OS versions.
>
> The reason why we offer gcc variants is when a port needs to build with fortran or java. Clang ports don't provide fortran or java compilers.

I originally wrote the clang variant when gcc was the default compiler
in macports :-) I could take it out now.