Re: Adding MPI back to Boost
Anyone opposed to me pushes the proposed changes and marking them fixed? Sean Farley writes: Ryan Schmidt writes: 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 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, clang35, debug, mpich, mpich_devel, [+]no_single, [+]no_static, openmpi, openmpi_devel, python25, python26, [+]python27, python31, python32, python33, python34, regex_match_extra, universal The reason I wrote the mpi and compilers portgroup was because there was no way to make sure the same compiler for both is selected. For example, $ port install boost +clang35 +mpich will install mpich (built with clang35 compilers) and boost (built with clang35 compilers). Only if mpich had not already been installed with a different variant, since MacPorts does not have the capability to declare dependencies on variants (ticket #126). Not in this case. The mpi portgroup forces the same active compilers. Is the correspondence of variants between e.g. boost and mpich required? In other words, if mpich is installed with +clang35, does that mean boost *must* use the +clang35 variant as well if one wants to use the +mpich variant, or would it work if +clang34 or clang from Xcode is used for boost? Yes, the same must be used across the board. The clang provided by Xcode can be used, of course, which is the default: $ port install boost +mpich will install mpich (built with Xcode compilers) and boost (built with Xcode compilers). This will change depending on the OS version. Under what circumstances would using Xcode clang not be sufficient? In other words, why would we ever want MacPorts clang variants? As Eric pointed out, it's for experimenting. This is exactly the same as the reason ATLAS uses different compilers: sometimes there is a speed improvement. Perhaps you're missing that MPI is a library that provide compiler *wrappers*? If a package needs MPI then that package is compiled with: CC=mpicc CXX=mpicxx FC=mpifort etc. Sure, I'm missing that, and probably a lot of other things. For example: what is the goal? What does adding mpi support to boost do? Why would someone want this? So that a package could use Boost.MPI (such as dolfin does). MPI falls under the category of scientific computing. This changes a few presumptions: the goal here is numerical computation (matrix vector operations). Having one implementation just isn't feasible. Science users want to experiment with each combination. You could say it's part of their nature. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Adding MPI back to Boost
On Dec 14, 2014, at 2:28 AM, Sean Farley s...@macports.org wrote: So, I've added support into the compilers portgroup for working with the compiler.blacklist variable but that doesn't fix the issue that Ryan tried to fix with r125939: https://trac.macports.org/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 variants). This seems like a good idea. Unless (a) you can use gcc for all of boost’s dependents and (b) there are actual use cases where this would be useful, I’d say that removing gcc variants is a good idea. Mixing libc++ and libstdc++ in boost dependents is bound to lead to problems. -- Mark Moll signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Adding MPI back to Boost
On Dec 14, 2014, at 2:28 AM, Sean Farley wrote: So, I've added support into the compilers portgroup for working with the compiler.blacklist variable but that doesn't fix the issue that Ryan tried to fix with r125939: https://trac.macports.org/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 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? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Adding MPI back to Boost
Mark Moll writes: On Dec 14, 2014, at 2:28 AM, Sean Farley s...@macports.org wrote: So, I've added support into the compilers portgroup for working with the compiler.blacklist variable but that doesn't fix the issue that Ryan tried to fix with r125939: https://trac.macports.org/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 variants). This seems like a good idea. Unless (a) you can use gcc for all of boost’s dependents and (b) there are actual use cases where this would be useful, I’d say that removing gcc variants is a good idea. Mixing libc++ and libstdc++ in boost dependents is bound to lead to problems. (a) That would require depending on a variant which I don't want to put the work into. I wrote a script to do this manually for myself but it is still a headache. (b) Depends on how useful you think testing different compiler speed / output is: I would have used it to test dolfin (FEniCS) builds with gcc vs clang. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Adding MPI back to Boost
Ryan Schmidt writes: On Dec 14, 2014, at 2:28 AM, Sean Farley wrote: So, I've added support into the compilers portgroup for working with the compiler.blacklist variable but that doesn't fix the issue that Ryan tried to fix with r125939: https://trac.macports.org/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 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. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Adding MPI back to Boost
On Dec 14, 2014, at 11:41 AM, Sean Farley wrote: Ryan Schmidt writes: On Dec 14, 2014, at 2:28 AM, Sean Farley wrote: So, I've added support into the compilers portgroup for working with the compiler.blacklist variable but that doesn't fix the issue that Ryan tried to fix with r125939: https://trac.macports.org/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 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. 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 clang would not? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Adding MPI back to Boost
Ryan Schmidt writes: On Dec 14, 2014, at 11:41 AM, Sean Farley wrote: Ryan Schmidt writes: On Dec 14, 2014, at 2:28 AM, Sean Farley wrote: So, I've added support into the compilers portgroup for working with the compiler.blacklist variable but that doesn't fix the issue that Ryan tried to fix with r125939: https://trac.macports.org/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 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. 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 clang would not? ... ? 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, clang35, debug, mpich, mpich_devel, [+]no_single, [+]no_static, openmpi, openmpi_devel, python25, python26, [+]python27, python31, python32, python33, python34, regex_match_extra, universal The reason I wrote the mpi and compilers portgroup was because there was no way to make sure the same compiler for both is selected. For example, $ port install boost +clang35 +mpich will install mpich (built with clang35 compilers) and boost (built with clang35 compilers). The clang provided by Xcode can be used, of course, which is the default: $ port install boost +mpich will install mpich (built with Xcode compilers) and boost (built with Xcode compilers). This will change depending on the OS version. Perhaps you're missing that MPI is a library that provide compiler *wrappers*? If a package needs MPI then that package is compiled with: CC=mpicc CXX=mpicxx FC=mpifort etc. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
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 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, clang35, debug, mpich, mpich_devel, [+]no_single, [+]no_static, openmpi, openmpi_devel, python25, python26, [+]python27, python31, python32, python33, python34, regex_match_extra, universal The reason I wrote the mpi and compilers portgroup was because there was no way to make sure the same compiler for both is selected. For example, $ port install boost +clang35 +mpich will install mpich (built with clang35 compilers) and boost (built with clang35 compilers). Only if mpich had not already been installed with a different variant, since MacPorts does not have the capability to declare dependencies on variants (ticket #126). Is the correspondence of variants between e.g. boost and mpich required? In other words, if mpich is installed with +clang35, does that mean boost *must* use the +clang35 variant as well if one wants to use the +mpich variant, or would it work if +clang34 or clang from Xcode is used for boost? The clang provided by Xcode can be used, of course, which is the default: $ port install boost +mpich will install mpich (built with Xcode compilers) and boost (built with Xcode compilers). This will change depending on the OS version. Under what circumstances would using Xcode clang not be sufficient? In other words, why would we ever want MacPorts clang variants? Perhaps you're missing that MPI is a library that provide compiler *wrappers*? If a package needs MPI then that package is compiled with: CC=mpicc CXX=mpicxx FC=mpifort etc. Sure, I'm missing that, and probably a lot of other things. For example: what is the goal? What does adding mpi support to boost do? Why would someone want this? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Adding MPI back to Boost
On Sunday, December 14, 2014, Ryan Schmidt ryandes...@macports.org wrote: 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 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, clang35, debug, mpich, mpich_devel, [+]no_single, [+]no_static, openmpi, openmpi_devel, python25, python26, [+]python27, python31, python32, python33, python34, regex_match_extra, universal The reason I wrote the mpi and compilers portgroup was because there was no way to make sure the same compiler for both is selected. For example, $ port install boost +clang35 +mpich will install mpich (built with clang35 compilers) and boost (built with clang35 compilers). Only if mpich had not already been installed with a different variant, since MacPorts does not have the capability to declare dependencies on variants (ticket #126). Is the correspondence of variants between e.g. boost and mpich required? In other words, if mpich is installed with +clang35, does that mean boost *must* use the +clang35 variant as well if one wants to use the +mpich variant, or would it work if +clang34 or clang from Xcode is used for boost? The clang provided by Xcode can be used, of course, which is the default: $ port install boost +mpich will install mpich (built with Xcode compilers) and boost (built with Xcode compilers). This will change depending on the OS version. Under what circumstances would using Xcode clang not be sufficient? In other words, why would we ever want MacPorts clang variants? Because people using mpich are typically interested in how their code compiles under multiple different compilers, because they are often targeting systems other than their mac with the software. And the different compiler wrapping versions are not variants of mpich, but are sub-ports that can be installed side by side and explicitly depended upon. - Eric ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Adding MPI back to Boost
Ryan Schmidt writes: 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 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, clang35, debug, mpich, mpich_devel, [+]no_single, [+]no_static, openmpi, openmpi_devel, python25, python26, [+]python27, python31, python32, python33, python34, regex_match_extra, universal The reason I wrote the mpi and compilers portgroup was because there was no way to make sure the same compiler for both is selected. For example, $ port install boost +clang35 +mpich will install mpich (built with clang35 compilers) and boost (built with clang35 compilers). Only if mpich had not already been installed with a different variant, since MacPorts does not have the capability to declare dependencies on variants (ticket #126). Not in this case. The mpi portgroup forces the same active compilers. Is the correspondence of variants between e.g. boost and mpich required? In other words, if mpich is installed with +clang35, does that mean boost *must* use the +clang35 variant as well if one wants to use the +mpich variant, or would it work if +clang34 or clang from Xcode is used for boost? Yes, the same must be used across the board. The clang provided by Xcode can be used, of course, which is the default: $ port install boost +mpich will install mpich (built with Xcode compilers) and boost (built with Xcode compilers). This will change depending on the OS version. Under what circumstances would using Xcode clang not be sufficient? In other words, why would we ever want MacPorts clang variants? As Eric pointed out, it's for experimenting. This is exactly the same as the reason ATLAS uses different compilers: sometimes there is a speed improvement. Perhaps you're missing that MPI is a library that provide compiler *wrappers*? If a package needs MPI then that package is compiled with: CC=mpicc CXX=mpicxx FC=mpifort etc. Sure, I'm missing that, and probably a lot of other things. For example: what is the goal? What does adding mpi support to boost do? Why would someone want this? So that a package could use Boost.MPI (such as dolfin does). MPI falls under the category of scientific computing. This changes a few presumptions: the goal here is numerical computation (matrix vector operations). Having one implementation just isn't feasible. Science users want to experiment with each combination. You could say it's part of their nature. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
