Request for comments: mpi and using multiple compilers

[Ryan Schmidt]

On Jul 24, 2013, at 13:55, Sean Farley wrote:

> If the port wants to do something specialized then it could simply put
> the special code in an if-block:
> 
> if {[variant_isset gcc46]} {
>  ...
> }

That's true…


>> 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"
> }

If a port doesn't support gcc46, it should not offer a gcc46 variant.


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

Oh, so instead of specifying which compilers the port supports, you want to specify which compilers the port does *not* support? I suppose that would mirror what MacPorts base does.

However, if you want to do that, it would be confusing if "multiplecompilers.blacklist" did not use the same compiler names as "compiler.blacklist". In the latter, the compiler name is e.g. "macports-gcc-4.6" not "gcc46".


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

As I said, the reason for compiler variants is to offer the user a choice when needing to build with fortran or java. Clang ports and Apple GCC ports do not offer fortran or java, so in my view there would be no reason to ever offer variants for those compilers.