[100629] trunk/dports/science/mpich/Portfile

[Sean Farley]

On Tue, Dec 18, 2012 at 9:06 AM, Eric A. Borisch <eborisch at macports.org> wrote:
> On Mon, Dec 17, 2012 at 11:43 PM, Ryan Schmidt <ryandesign at macports.org>
> wrote:
>>
>>
>> On Dec 17, 2012, at 22:16, eborisch at macports.org wrote:
>>
>> > Revision: 100629
>> >          https://trac.macports.org/changeset/100629
>> > Author:   eborisch at macports.org
>> > Date:     2012-12-17 20:16:28 -0800 (Mon, 17 Dec 2012)
>> > Log Message:
>> > -----------
>> > mpich[-devel]: Update to use compiler_blacklist_versions. Only create
>> > clang variant when compatible.
>> >
>> > Modified Paths:
>> > --------------
>> >    trunk/dports/science/mpich/Portfile
>> >
>> > Modified: trunk/dports/science/mpich/Portfile
>> > ===================================================================
>> > --- trunk/dports/science/mpich/Portfile       2012-12-18 00:57:35 UTC
>> > (rev 100628)
>> > +++ trunk/dports/science/mpich/Portfile       2012-12-18 04:16:28 UTC
>> > (rev 100629)
>> > @@ -2,6 +2,7 @@
>> > # $Id$
>> >
>> > PortSystem          1.0
>> > +PortGroup           compiler_blacklist_versions 1.0
>> >
>> > name                mpich
>> > set pkgname         mpich2
>> > @@ -84,6 +85,9 @@
>> >
>> > depends_lib-append  port:libxml2
>> >
>> > +# Linker for Apple clang version 431.11.66 currently segfaults
>> > +# See https://trac.macports.org/ticket/36654#comment:9
>> > +compiler.blacklist-append   {clang >= 421.11.66}
>>
>> 431.11.66 or 421.11.66?
>>
>
> I think the one that is evaluated (421.11.66) is the correct one, but I'll
> have to check on my ML machine this evening.
>
> I'm debating having the +clang variant set as default (when not blacklisted)
> and the +llvm variant set as default otherwise, and potentially adding a
> check that one of the compiler variants must be selected (so it is explicit
> which compiler is being wrapped.) Any thoughts on that (wrt old systems?)

I meant to send this information earlier; sorry. Actually, you can
avoid blacklisting the clang compiler by adding this code to a
pre-configure stage,

    #   https://trac.mcs.anl.gov/projects/mpich2/ticket/1547
    if {${configure.compiler} == "clang"} {
        configure.env-append    ac_cv_tls=none
    }

I noticed that there is still some clang tls weirdness in mpich 3.0rc1
and have meaning to ask Dave about it but just haven't had time. I'll
be at the lab this Thursday and Friday and will try to stop by his
office. Else, I'll just file a new bug.