ebori...@macports.org writes:
> On Mon, Aug 5, 2013 at 6:09 PM, Sean Farley wrote:
>>
>> ebori...@macports.org writes:
>>> I personally swap back and forth between variants of mpich
>>> when I'm testing my own MPI code (why, oh why, doesn't clang have
>>> OpenMP support yet?)
>>
>> Because there
On Mon, Aug 5, 2013 at 6:09 PM, Sean Farley wrote:
>
> ebori...@macports.org writes:
>> I personally swap back and forth between variants of mpich
>> when I'm testing my own MPI code (why, oh why, doesn't clang have
>> OpenMP support yet?)
>
> Because there is almost no benefit for parallel applic
ebori...@macports.org writes:
> On Thu, Jul 25, 2013 at 9:31 PM, Sean Farley wrote:
>>
>> ebori...@macports.org writes:
>>
>>> Again, I haven't scoured the whole thread, but would making sub-ports
>>> rather than variants for the different compilers help? The
>>> dependent's +gcc44+mpich could r
On Thu, Jul 25, 2013 at 9:31 PM, Sean Farley wrote:
>
> ebori...@macports.org writes:
>
>> On Thursday, July 25, 2013, Sean Farley wrote:
>>
>>>
>>> ebori...@ieee.org writes:
>>>
>>> > On Thursday, July 25, 2013, Sean Farley wrote:
>>> >>
>>> >> But really, we're at the whim of what the macports
ebori...@macports.org writes:
> On Thursday, July 25, 2013, Sean Farley wrote:
>
>>
>> ebori...@ieee.org writes:
>>
>> > On Thursday, July 25, 2013, Sean Farley wrote:
>> >>
>> >> But really, we're at the whim of what the macports community whats to do
>> >> in this situation. Since my Ph.D is r
On Thursday, July 25, 2013, Sean Farley wrote:
>
> ebori...@ieee.org writes:
>
> > On Thursday, July 25, 2013, Sean Farley wrote:
> >>
> >> But really, we're at the whim of what the macports community whats to do
> >> in this situation. Since my Ph.D is riding on getting a working mpi +
> >> fort
ebori...@ieee.org writes:
> On Thursday, July 25, 2013, Sean Farley wrote:
>>
>> But really, we're at the whim of what the macports community whats to do
>> in this situation. Since my Ph.D is riding on getting a working mpi +
>> fortran, I'd very much like to iron out these issues and get the po
On Thursday, July 25, 2013, Sean Farley wrote:
>
> But really, we're at the whim of what the macports community whats to do
> in this situation. Since my Ph.D is riding on getting a working mpi +
> fortran, I'd very much like to iron out these issues and get the ports
> chugging along!
>
Does mpic
dstru...@gmail.com writes:
> Hi Sean,
>
> We both have 'arpack @3.1.3+mpich' installed but they were built with
>> two very different compilers: mine with clang and yours with gcc45. If
>> we force the user to specify the compiler then we can use
>> require_active_variants to make sure everything
Hi Sean,
We both have 'arpack @3.1.3+mpich' installed but they were built with
> two very different compilers: mine with clang and yours with gcc45. If
> we force the user to specify the compiler then we can use
> require_active_variants to make sure everything is in line, e.g.
>
> arpack +mpich +
dstru...@gmail.com writes:
>> Ah, that's something I tried to do at first as well. It's not possible
>> since it would lead to non-unique builds. For example, let's assume
>> arpack has a known problem with gcc46 and an unknown bug with
>> gcc45. In the arpack portfile, we'll put an error if +mpi
> > I think in most cases that if you use MPI, then there is no need to
> specify
> > the underlying compiler also (since compiling even non-MPI code in the
> > package with mpich +gfortran is the same as just using gfortran).
> Recently,
> > we sorted this out for the arpack port.
>
> Ah, that's s
ryandes...@macports.org writes:
> 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 n
dstru...@mit.edu writes:
> On Sat, Jul 20, 2013 at 7:28 PM, Sean Farley wrote:
>
>> Hi all,
>>
>> 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
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 abov
ryandes...@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
>> tr
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 gro
On Sat, Jul 20, 2013 at 7:28 PM, Sean Farley wrote:
> Hi all,
>
> 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.
>
Sounds like a g
Hi all,
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 (should
19 matches
Mail list logo
