Re: Rev bumping mpi dependents

Joshua Root writes: > On 2016-7-21 09:24 , Brandon Allbery wrote: >> On Wed, Jul 20, 2016 at 7:21 PM, Sean Farley > > wrote: >> >> OpenMPI just released 2.0 which will change the name of the libraries. >> I'm guessing I

Re: Rev bumping mpi dependents

On 2016-7-21 09:24 , Brandon Allbery wrote: On Wed, Jul 20, 2016 at 7:21 PM, Sean Farley > wrote: OpenMPI just released 2.0 which will change the name of the libraries. I'm guessing I should revbump all the dependents to force a rebuild but

Re: Rev bumping mpi dependents

On Wed, Jul 20, 2016 at 7:21 PM, Sean Farley wrote: > OpenMPI just released 2.0 which will change the name of the libraries. > I'm guessing I should revbump all the dependents to force a rebuild but > is this something that `port rev-upgrade` should handle? > I think you can

Rev bumping mpi dependents

OpenMPI just released 2.0 which will change the name of the libraries. I'm guessing I should revbump all the dependents to force a rebuild but is this something that `port rev-upgrade` should handle? ___ macports-dev mailing list

Re: Adding MPI back to Boost

the clang 3.x provided by Xcode in some way? The MacPorts clang ports would be able to use MPI somehow, while Xcode clang would not? ... ? That's a bit how I feel about this mpi business, yes. :-/ First of all, for the sake of completeness, the list of variants would be: $ port

Adding MPI back to Boost

Is there anything wrong with this proposed fix? If no one objects, I'll push my changesets which 1) add blacklist support to the compilers portgroup and 2) add mpi portgroup to boost (but remove gcc variants). ___ macports-dev mailing list macports-dev

Re: Adding MPI back to Boost

instead that the fix is just to remove the gcc variants: mpi.setup -gcc Is there anything wrong with this proposed fix? If no one objects, I'll push my changesets which 1) add blacklist support to the compilers portgroup and 2) add mpi portgroup to boost (but remove gcc variants

Re: Adding MPI back to Boost

that the fix is just to remove the gcc variants: mpi.setup -gcc Is there anything wrong with this proposed fix? If no one objects, I'll push my changesets which 1) add blacklist support to the compilers portgroup and 2) add mpi portgroup to boost (but remove gcc variants). Right, using gcc variants

Re: Adding MPI back to Boost

/changeset/125939 It seems instead that the fix is just to remove the gcc variants: mpi.setup -gcc Is there anything wrong with this proposed fix? If no one objects, I'll push my changesets which 1) add blacklist support to the compilers portgroup and 2) add mpi portgroup to boost (but remove gcc

Re: Adding MPI back to Boost

It seems instead that the fix is just to remove the gcc variants: mpi.setup -gcc Is there anything wrong with this proposed fix? If no one objects, I'll push my changesets which 1) add blacklist support to the compilers portgroup and 2) add mpi portgroup to boost (but remove gcc variants

Re: Adding MPI back to Boost

mpi portgroup to boost (but remove gcc variants). Right, using gcc variants causes the use of libstdc++ which causes the problem on Mavericks and later. So, without gcc variants, what variants remain? clang 3.x and all versions of dragonegg. Multiple that set with all the mpi choices, too

Re: Adding MPI back to Boost

portgroup and 2) add mpi portgroup to boost (but remove gcc variants). Right, using gcc variants causes the use of libstdc++ which causes the problem on Mavericks and later. So, without gcc variants, what variants remain? clang 3.x and all versions of dragonegg. Multiple that set with all

Re: Adding MPI back to Boost

On Dec 14, 2014, at 12:21 PM, Sean Farley wrote: Ryan Schmidt writes: So, this would add clang33, clang34, clang35 variants, for example? But these would be different from the clang 3.x provided by Xcode in some way? The MacPorts clang ports would be able to use MPI somehow, while Xcode

Re: Adding MPI back to Boost

way? The MacPorts clang ports would be able to use MPI somehow, while Xcode clang would not? ... ? That's a bit how I feel about this mpi business, yes. First of all, for the sake of completeness, the list of variants would be: $ port info boost boost @1.56.0_2 (devel) Variants

Re: Adding MPI back to Boost

MPI somehow, while Xcode clang would not? ... ? That's a bit how I feel about this mpi business, yes. :-/ First of all, for the sake of completeness, the list of variants would be: $ port info boost boost @1.56.0_2 (devel) Variants: clang31, clang32, clang33, clang34

Re: mpi

On Oct 1, 2014, at 1:00 PM, Sean Farley wrote: Also, having conditional code for which compiler to use based on the OS (and sprinkled all throughout the code) is a maintenance headache. Ports shouldn't do that. Ports should set compiler.blacklist to indicate which compilers won't work.

Re: mpi

Yes, atlas has a bunch of compiler variants. I would love for most or all of them to go away. But part of atlas needs fortran so it needs to deal with that at least. And I believe Vince argued that for atlas and other performance-critical scientific software it is beneficial to be able to

Re: mpi

vincent writes: Yes, atlas has a bunch of compiler variants. I would love for most or all of them to go away. But part of atlas needs fortran so it needs to deal with that at least. And I believe Vince argued that for atlas and other performance-critical scientific software it is

Re: mpi

On Wed, Oct 1, 2014 at 1:30 PM, Sean Farley s...@macports.org wrote: - Always use clang for C/C++ - Drop PPC support There are a lot of people relying on MacPorts to keep PPCs running. In addition, I suspect that 99% of use cases are better handled by: - Always use clang on 10.9 (or maybe

Re: mpi

On Oct 1, 2014, at 1:36 PM, Brandon Allbery allber...@gmail.com wrote: On Wed, Oct 1, 2014 at 1:30 PM, Sean Farley s...@macports.org wrote: - Always use clang for C/C++ - Drop PPC support There are a lot of people relying on MacPorts to keep PPCs running. they probably shouldn't be. I

Re: mpi

Daniel J. Luke writes: On Oct 1, 2014, at 1:36 PM, Brandon Allbery allber...@gmail.com wrote: On Wed, Oct 1, 2014 at 1:30 PM, Sean Farley s...@macports.org wrote: - Always use clang for C/C++ - Drop PPC support There are a lot of people relying on MacPorts to keep PPCs running. they

mpi

on 10.9+. I removed the compiler variants from the boost port, but this has the effect of making it impossible to install boost with mpi support, which apparently some ports like dolphin require. I have to say I have no understanding of what mpi is or what the mpi portgroup is doing. Sean, could

Re: mpi

this to the mixing of C++ runtimes on 10.9+. I removed the compiler variants from the boost port, but this has the effect of making it impossible to install boost with mpi support, which apparently some ports like dolphin require. I have to say I have no understanding of what mpi is or what the mpi

Re: mpi

On Sep 30, 2014, at 4:10 PM, Sean Farley wrote: --- Fortran --- While the above matrix was relatively straight-forward to implement there was one glaring problem: fortran. LLVM / clang does not provide it. Wonderful. What portion of ports that want mpi also need a fortran

Re: mpi

Ryan Schmidt writes: This creates the scenario of: does the port want the full suite of, for example, gcc (meaning both C and fortran) or just the fortran compiler. And which of these two strategies does the mpi portgroup employ? Both, that's why there is a 'require_fortran' variable

Re: mpi

On Sep 30, 2014, at 7:04 PM, Sean Farley wrote: This is pretty much was is done (modulo the blacklist). If I understand correctly, though, you want to remove gcc from being able to be used as a compiler? This would be a serious limitation. Removed as a C/C++/ObjC/ObjC++ compiler, yes. In

Re: mpi

Ryan Schmidt writes: On Sep 30, 2014, at 7:04 PM, Sean Farley wrote: This is pretty much was is done (modulo the blacklist). If I understand correctly, though, you want to remove gcc from being able to be used as a compiler? This would be a serious limitation. Removed as a

Re: mpi

On Sep 30, 2014, at 8:08 PM, Sean Farley wrote: Ryan Schmidt writes: On Sep 30, 2014, at 7:04 PM, Sean Farley wrote: This is pretty much was is done (modulo the blacklist). If I understand correctly, though, you want to remove gcc from being able to be used as a compiler? This would be

Re: mpi

Ryan Schmidt writes: On Sep 30, 2014, at 8:08 PM, Sean Farley wrote: Ryan Schmidt writes: On Sep 30, 2014, at 7:04 PM, Sean Farley wrote: This is pretty much was is done (modulo the blacklist). If I understand correctly, though, you want to remove gcc from being able to be used as a

Re: mpi

On Sep 30, 2014, at 9:08 PM, Sean Farley wrote: Ryan Schmidt writes: The question, to me, is: why is it still not possible to distinguish foo+gcc and foo+clang in MacPorts? I'm not sure what you mean. Why can't all a port's variants be installed at the same time? $ port install

Re: mpi

Ryan Schmidt writes: On Sep 30, 2014, at 9:08 PM, Sean Farley wrote: Ryan Schmidt writes: The question, to me, is: why is it still not possible to distinguish foo+gcc and foo+clang in MacPorts? I'm not sure what you mean. Why can't all a port's variants be installed at the same

Re: mpi

On Sep 30, 2014, at 10:09 PM, Ryan Schmidt ryandes...@macports.org wrote: On Sep 30, 2014, at 9:08 PM, Sean Farley wrote: Ryan Schmidt writes: The question, to me, is: why is it still not possible to distinguish foo+gcc and foo+clang in MacPorts? I'm not sure what you mean. Why

Re: mpi

On Sep 30, 2014, at 9:44 PM, Lawrence Velázquez lar...@macports.org wrote: On Sep 30, 2014, at 10:09 PM, Ryan Schmidt ryandes...@macports.org wrote: On Sep 30, 2014, at 9:08 PM, Sean Farley wrote: Ryan Schmidt writes: The question, to me, is: why is it still not possible to

Re: mpi

On Sep 30, 2014, at 10:52 PM, Ryan Schmidt ryandes...@macports.org wrote: I understand the proposal, but I don't agree that we should implement it. It does seem like it would introduce a great deal of complexity to address what is clearly (to me, at least) an antipattern (using variants to

Re: mpi

On Sep 30, 2014, at 9:25 PM, Sean Farley wrote: That's not what variants are for. That's what subports are for. Subports are trying to solve this but expose the implementation level too far up. Only one solution should exist to depending on a variant. Subports, unfortunately, put all the

Re: mpi

Lawrence Velázquez writes: On Sep 30, 2014, at 10:52 PM, Ryan Schmidt ryandes...@macports.org wrote: I understand the proposal, but I don't agree that we should implement it. It does seem like it would introduce a great deal of complexity to address what is clearly (to me, at least) an

Re: mpi

Ryan Schmidt writes: On Sep 30, 2014, at 9:25 PM, Sean Farley wrote: That's not what variants are for. That's what subports are for. Subports are trying to solve this but expose the implementation level too far up. Only one solution should exist to depending on a variant. Subports,

Re: mpi

On Sep 30, 2014, at 10:35 PM, Sean Farley wrote: Lawrence Velázquez writes: On Sep 30, 2014, at 10:52 PM, Ryan Schmidt wrote: I understand the proposal, but I don't agree that we should implement it. It does seem like it would introduce a great deal of complexity to address what is

Re: mpi

On Sep 30, 2014, at 10:48 PM, Sean Farley wrote: Ryan Schmidt writes: On Sep 30, 2014, at 9:25 PM, Sean Farley wrote: That's not what variants are for. That's what subports are for. Subports are trying to solve this but expose the implementation level too far up. Only one solution

Re: mpi

Ryan Schmidt writes: On Sep 30, 2014, at 10:35 PM, Sean Farley wrote: Lawrence Velázquez writes: On Sep 30, 2014, at 10:52 PM, Ryan Schmidt wrote: I understand the proposal, but I don't agree that we should implement it. It does seem like it would introduce a great deal of complexity

Re: mpi

On Wed, Oct 1, 2014 at 12:04 AM, Ryan Schmidt ryandes...@macports.org wrote: However, many ports have gcc variants from years ago before we fully understood the C++ standard library mismatch issues Said mismatch issues didn't exist until Apple switched the default compiler to clang and

Re: mpi

that however. Also, atlas already builds itself multiple times with different compiler options to get best performance, which is why building atlas takes so long. I already fixed boost by removing the use of the mpi portgroup. If mpi support needs to be brought back, then a general solution needs

Re: mpi

would love for most or all of them to go away. But part of atlas needs fortran so it needs to deal with that at least. I would love for fortran to go away, too, but certain packages will need different compilers. I already fixed boost by removing the use of the mpi portgroup. If mpi support

Re: mpi

already fixed boost by removing the use of the mpi portgroup. If mpi support needs to be brought back, then a general solution needs to be found for the mpi portgroup, which based on what you said earlier might be as simple as deferring its work until the pre-configure block. MPI support

Re: Compilers and MPI Port Groups

}. The noteworthy changesets are: mpi-doc: new port to abstract docs for mpich and openmpi https://smf.io/macports/changeset/2d0f20f8414b7b676f0c72079938ff3fc6dccb86 mpich_select: rename to mpi_select so all mpi ports can use it https://smf.io/macports/changeset

Re: Compilers and MPI Port Groups

are: mpi-doc: new port to abstract docs for mpich and openmpi https://smf.io/macports/changeset/2d0f20f8414b7b676f0c72079938ff3fc6dccb86 mpich_select: rename to mpi_select so all mpi ports can use it https://smf.io/macports/changeset/0946ba1629b857a1cc3ca5ae098df616c30dc2a4 mpich: use non-conflicting

Re: Compilers and MPI Port Groups

lar...@macports.org writes: On Jan 19, 2014, at 6:41 PM, Sean Farley s...@macports.org wrote: Any objections before I push? Not sure they're objections so much as nitpicks. Any helpful feedback is appreciated! set compilers.list {cc cxx cpp objc fc f77 f90} There's a configure.objcxx

Re: Compilers and MPI Port Groups

s...@macports.org writes: s...@macports.org writes: s...@macports.org writes: Hello all and Happy Boxing Day! I have done a complete rewrite of the compilers and mpi port groups based on suggestions from previous emails. I will try to keep this email short and provide links for those

Re: Compilers and MPI Port Groups

and mpi port groups based on suggestions from previous emails. I will try to keep this email short and provide links for those that want to know more. Highlights: - specify which compilers to set via compilers.choose, e.g. 'compilers.choose f77 f90 fc' - functions for testing

Re: Compilers and MPI Port Groups

On Jan 19, 2014, at 6:41 PM, Sean Farley s...@macports.org wrote: Any objections before I push? Not sure they're objections so much as nitpicks. set compilers.list {cc cxx cpp objc fc f77 f90} There's a configure.objcxx option now. # dragonegg versions will always match the corresponding

Re: Compilers and MPI Port Groups

s...@macports.org writes: s...@macports.org writes: Hello all and Happy Boxing Day! I have done a complete rewrite of the compilers and mpi port groups based on suggestions from previous emails. I will try to keep this email short and provide links for those that want to know more

Re: Compilers and MPI Port Groups

s...@macports.org writes: Hello all and Happy Boxing Day! I have done a complete rewrite of the compilers and mpi port groups based on suggestions from previous emails. I will try to keep this email short and provide links for those that want to know more. Highlights: - specify which

Compilers and MPI Port Groups

Hello all and Happy Boxing Day! I have done a complete rewrite of the compilers and mpi port groups based on suggestions from previous emails. I will try to keep this email short and provide links for those that want to know more. Highlights: - specify which compilers to set via

Re: [111271] trunk/dports/science/ocaml-mpi/Portfile

On Sep 17, 2013, at 22:06, ebori...@macports.org wrote: Revision: 111271 https://trac.macports.org/changeset/111271 Author: ebori...@macports.org Date: 2013-09-17 20:06:42 -0700 (Tue, 17 Sep 2013) Log Message: --- ocaml-mpi: Update to use new mpich-default

Re: [111271] trunk/dports/science/ocaml-mpi/Portfile

2013) Log Message: --- ocaml-mpi: Update to use new mpich-default Modified Paths: -- trunk/dports/science/ocaml-mpi/Portfile Modified: trunk/dports/science/ocaml-mpi/Portfile === --- trunk

Re: [111271] trunk/dports/science/ocaml-mpi/Portfile

to install ocaml-mpi. That includes new users and the buildbots, and therefore also any users who get the precompiled binaries. I tried it just now and the build succeeded, but I don't know what effect the incorrect MPILIBDIR had. You could fix this by changing the if statement. Check for a file

Re: [111271] trunk/dports/science/ocaml-mpi/Portfile

. This will affect any users who haven't already installed mpich-default by the time they ask to install ocaml-mpi. That includes new users and the buildbots, and therefore also any users who get the precompiled binaries. I tried it just now and the build succeeded, but I don't know what effect

Re: [111271] trunk/dports/science/ocaml-mpi/Portfile

On Sep 18, 2013, at 10:45 PM, Eric A. Borisch ebori...@macports.org wrote: On Wednesday, September 18, 2013, Ryan Schmidt wrote: This is concerning, because it means the port builds differently depending on what ports the user already has installed. This won't work right if the user gets a

Re: Request for comments: mpi and using multiple compilers

ebori...@macports.org writes: On Mon, Aug 5, 2013 at 6:09 PM, Sean Farley s...@macports.org 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

Re: Request for comments: mpi and using multiple compilers

On Mon, Aug 5, 2013 at 6:09 PM, Sean Farley s...@macports.org 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

Re: Request for comments: mpi and using multiple compilers

) dependents of that package. True but I don't think that would buy us anything in this case. The user would still have to manually switch the dependents of the mpi ports. 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

Re: Request for comments: mpi and using multiple compilers

.) BUT: How about this idea which may fit with both of our conceptions of how things should work? A default variant for fortran is set according to whichever one was used for building MPI. Then, you can still do port install arpack +mpich without worrying which compiler was used to build mpich

Re: Request for comments: mpi and using multiple compilers

understand the point of your example.) The ability to deactivate a dependent port all goes back to this ticket: https://trac.macports.org/ticket/126 It is quite the hydra that lurks in variants. What I did is write a script that switches my mpi + compiler variants for all dependent ports. BUT: How

RE Request for comments: mpi and using multiple compilers

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 mpich

Re: Request for comments: mpi and using multiple compilers

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 ports

Re: Request for comments: mpi and using multiple compilers

On Thursday, July 25, 2013, Sean Farley wrote: ebori...@ieee.org javascript:; 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

Re: Request for comments: mpi and using multiple compilers

on getting a working mpi + fortran, I'd very much like to iron out these issues and get the ports chugging along! Does mpich +gccXX not get you to working fortran and MPI? I'll try to read through some of this thread later, but just looking for clarification on that point. Again

Re: Request for comments: mpi and using multiple compilers

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 mpich +gccXX not get you to working fortran and MPI? I'll try to read through some of this thread

Re: Request for comments: mpi and using multiple compilers

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 tree

Re: Request for comments: mpi and using multiple compilers

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

Re: Request for comments: mpi and using multiple compilers

dstru...@mit.edu writes: On Sat, Jul 20, 2013 at 7:28 PM, Sean Farley s...@macports.org 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

Re: Request for comments: mpi and using multiple compilers

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 needed seems

Re: Request for comments: mpi and using multiple compilers

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 something I

Re: Request for comments: mpi and using multiple compilers

+mpich +gfortran - mpich+gfortran will be used arpack +mpich +gcc45 - mpich+gcc45 will be used And this ensures that the same compiler is used on all machines with the same variants. On the other hand, sometimes it is necessary to enforce the same Fortran compiler used for MPI and for some

Request for comments: mpi and using multiple compilers

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

Re: Request for comments: mpi and using multiple compilers

On Sat, Jul 20, 2013 at 7:28 PM, Sean Farley s...@macports.org 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

Re: Request for comments: mpi and using multiple compilers

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

g95, Open MPI, HDF4, tcl-nap

/13841 Open MPI: Xgrid support http://trac.macosforge.org/projects/macports/ticket/13819 HDF4.2r2 http://trac.macosforge.org/projects/macports/ticket/13603 tcl-nap-6.4.0 http://trac.macosforge.org/projects/macports/ticket/13605 ___ macports-dev mailing list

Re: Open MPI

Markus, I found that it does not build if mpich2 is installed. Like a file conflict or a build-time conflict? opt/local/include/mpio.h installed by mpich2 conflicts with headers of Open MPI. I'm not a big fan of conflicting ports: So far we managed to make most port non-conflicting (e.g

Open MPI

Hello, I have just created a ticket for openmpi to suport fortran better. I found that it does not build if mpich2 is installed. If we do not allow both to install at the same time, (is there a counterpart of Conflicts field of Fink?) we do not need to put open before mpirun mpicc and mpif90.