Adding MPI back to Boost
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). ___ 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
co-installable qt4-mac and qt5-mac step1 : qt4-mac +concurrent
'evening! I finally got around to finishing up (or almost) my draft version for a qt4-mac port that can live alongside other (future) Qt port versions installed with the same approach: see https://trac.macports.org/ticket/46238 . Related submissions: https://trac.macports.org/ticket/46239 https://trac.macports.org/ticket/46240 Hope this helps! :) René ___ 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: [129459] trunk/dports/multimedia/mpv
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 14.12.2014 05:40 AM, Ryan Schmidt wrote: On Dec 13, 2014, at 10:01 PM, Mihai Moldovan wrote: On 14.12.2014 04:51 AM, Ryan Schmidt wrote: If it works for your use case in mpv, and still works for other ports using the github portgroup, go ahead. Hum, there are 468 ports making use of the github PortGroup. Testing all of them is out of question. But I can make sure those that are changing master_sites still behave like they behaved before. After getting some sleep. This change does indeed fix the issue for mpv, though. Right, most use the defaults, so I'd test one of those, then take a closer look at those that change master_sites. r129506 for the Portgroup change, r129507 for the mpv change. -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJUjiyzAAoJEB/WLtluJTqHLzUQAOM4ltldgHBqwTiilcvleukG boqV1QQzAd1IQg1kKlKOIvxliq0zsw6VIZ3g5vDxeMp6hmdUE9BIZAc7r6xbfmx+ QMgeOQ9oFZra64RRSE+jJ6Ka7DBi+WwWxcsDYTCsS010lQT22qUhBmtVZWmfrGj+ W++Xsp3BTF8t85GIo70xd6PkWNrjy0M/Os81qzIb06aZVUJeWnOJhM7vawfJxaI4 Ajejj5k+RyqWo4favgRKwPDMw32pzj48GcjMsZor+E2MIL9jqQFrB5BvpUgtV94B MzsFIv3YEpQDc651JqdmQcwa+nP/Vg+babuASauiVdZmo0Y4MQtwpIwyRyBJ7VaO iM327qFgJoLrxxOKuP67jJPnvk3bV7bx0ayTPviz7c6Py6XzjtZm2sK2sEWdF9Bq LIsmk0DctAkOy8T/P5Co6Gud12g5DERfmtzaggaw6EG3RSOZwubn7nP25GHabe6K uY9X4bcMOL+1kZ1d54sSZ/nhA8p/KCHPQqjPn67OSV86kHieMJJ7oM/ppt+FY0Zh FznVp6AgpQwUUNLsRbsTIpbx3qD+bEwC3yYshwqqZcYpzVcu2lRjVXwrZ8q8ydaD f8FihhTsY+BWhKSViPA4i7TYqfYnPxEpgHVzOejefCBl63016spi6UsDQKkPsHgk gxC4m31S6Cu2izKEhSjc =Rt26 -END PGP SIGNATURE- ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [129507] trunk/dports/multimedia/mpv/Portfile
On Dec 14, 2014, at 6:26 PM, io...@macports.org wrote:
Revision
129507
Author
io...@macports.org
Date
2014-12-14 16:26:55 -0800 (Sun, 14 Dec 2014)
Log Message
mpv: inline waf fetching.
Modified Paths
• trunk/dports/multimedia/mpv/Portfile
Diff
Modified: trunk/dports/multimedia/mpv/Portfile (129506 = 129507)
--- trunk/dports/multimedia/mpv/Portfile 2014-12-15 00:11:38 UTC (rev
129506)
+++ trunk/dports/multimedia/mpv/Portfile 2014-12-15 00:26:55 UTC (rev
129507)
+set waf_version 1.8.1
+set waf_distfilewaf-${waf_version}
+set mpv_distfile${distfiles}
+master_sites-append http://ftp.waf.io/pub/release:waf
+distfiles-append${waf_distfile}:waf
+extract.only-delete ${waf_distfile}
+
+checksums ${mpv_distfile} \
+rmd160 0c34377f400bdb0553866418442c32792866 \
+sha256
e7aa04852944eae4ebe0c38da83093e757f04741b98b3dd2cc4c2cdd3cea3e91 \
+${waf_distfile} \
+rmd160 d74bf5e8b2399098aef8e9bf57fb800a473be6a1 \
+sha256
ec658116ba0b96629d91fde0b32321849e866e0819f1e835c4c2c7f7ffe1a21d
Thanks. How common do you think this is -- port downloads waf before using it?
Might we need this in other ports as well?
-pre-configure {
-system -W ${worksrcpath} ${waf.python} bootstrap.py
+post-extract {
+xinstall -m 0644 -W ${distpath} ${waf_distfile} ${worksrcpath}/waf
}
Remember, as Larry said in response to another commit, that these quotation
marks are unnecessary, even if the values of the variables contain spaces,
which they don't anyway, so the quotation marks should be removed, so as not to
give the mistaken impression to others reading the portfile as an example that
the quotes are in some way helpful or needed. If this were a shell script, the
quotation marks would prevent problems when the variable value contains spaces,
but in Tcl that is not a problem.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [129507] trunk/dports/multimedia/mpv/Portfile
On Sun, Dec 14, 2014 at 7:50 PM, Ryan Schmidt ryandes...@macports.org
wrote:
-pre-configure {
-system -W ${worksrcpath} ${waf.python} bootstrap.py
+post-extract {
+xinstall -m 0644 -W ${distpath} ${waf_distfile}
${worksrcpath}/waf
}
Remember, as Larry said in response to another commit, that these
quotation marks are unnecessary, even if the values of the variables
contain spaces, which they don't anyway, so the quotation marks should be
removed, so as not to give the mistaken impression to others reading the
portfile as an example that the quotes are in some way helpful or needed.
If this were a shell script, the quotation marks would prevent problems
when the variable value contains spaces, but in Tcl that is not a problem.
If we're going to be pedantic, the braces around the variable names don't
do anything except in the case of ${waf.python} where they are required.
--
brandon s allbery kf8nh sine nomine associates
allber...@gmail.com ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [129507] trunk/dports/multimedia/mpv/Portfile
On Dec 14, 2014, at 7:55 PM, Brandon Allbery allber...@gmail.com wrote:
If we're going to be pedantic, the braces around the variable names don't do
anything except in the case of ${waf.python} where they are required.
True, but we seem to have settled on ${this} as our style in portfiles. It does
have the benefit of clearly delimiting the variable name, and quite a few
portfile options do require it.
Meanwhile, base code does $this all the time.
vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [129507] trunk/dports/multimedia/mpv/Portfile
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 15.12.2014 01:50 AM, Ryan Schmidt wrote:
Thanks. How common do you think this is -- port downloads waf before using
it? Might we need this in other ports as well?
I only had a superficial look, but it seems not be common. Most software bundles
waf directly, so that's a non-problem. I'd have to check more in depth, though.
-pre-configure {
-system -W ${worksrcpath} ${waf.python} bootstrap.py
+post-extract {
+xinstall -m 0644 -W ${distpath} ${waf_distfile} ${worksrcpath}/waf
}
Remember, as Larry said in response to another commit, that these quotation
marks are unnecessary, even if the values of the variables contain spaces,
which they don't anyway, so the quotation marks should be removed, so as not
to give the mistaken impression to others reading the portfile as an example
that the quotes are in some way helpful or needed. If this were a shell
script, the quotation marks would prevent problems when the variable value
contains spaces, but in Tcl that is not a problem.
Yes, but until I issue a commit changing that in all places at once, I want it
to be consistent.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCgAGBQJUjjM4AAoJEB/WLtluJTqHNkEP/ju/1Y1q8EIyzSmX/Yq/Hglk
aNjHDIgllq9ezjpJ/QGG90iSHYejh5HHs2TBeKjUhj+dEoD8OPDqoHylfjySmS+9
IGtyJAoiLE8HliDoEE8kYaMF812/HZ4e+TzV5Dq6ZZxHaffKNH5IglcwuLBBLRVQ
c4VKB+8eFdL9UskDt0NSi+qwqU4cxtpEu5E5XAjnc9Kr8ogSfScs5YYJzug0Q747
iy3I2Zx9zXL+KSm7rMvl9fC0v/L4atrPPC5VlAbyp11Z+XlM+S7SXshXiT8v8gWz
DNAYSQJpat31qnVEkFaVyTG5cc2eOO9rpgtYPZTD/jSE+f9tjckIE9P0UAmLwd1a
9jPa36+yabq556e1qcIObIA3HEBlhPZ/1f9WOCxm4JHMAMDw42ySRYxdnWy4TPQI
UuglP4XPR6R2LM9jdlO/ALLPv5w3m3PO6W1T8UwI+wDbxMTQ8YG/ksaMuhQGNTi2
d4dntFEk6ltq1hW0sPXEJsm7awFcwgVJZH738tyq+2q5D2wtRZgzPD1F5ozue9+y
q6KR+TFUYbaUoL+faxb+3WQ6+NA3dkA3X5HXl1ZVql+b+MHJSamhUzl2twTCI+gd
6eICgPwdoIQZxfsqjfjSgVc8M1XtvbEv3w9BGdKuLR1gJ0MNDQhwTUD9+lfHZpiG
rwGS2KijDoJCsWXR2XeE
=1nbN
-END PGP SIGNATURE-
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [129507] trunk/dports/multimedia/mpv/Portfile
On Dec 14, 2014, at 8:02 PM, Mihai Moldovan io...@macports.org wrote: Yes, but until I issue a commit changing that in all places at once I don't think this is worth making a huge commit to fix, and in fact I think that would be a bad idea. It's not as if the quotes are *wrong*, and it would be way too easy to make a mistake and remove the quoting from one of the places it *is* needed. I just wanted to bring it up so that others might think twice about blindly quoting in future commits. If we want to standardize this, it'd be best to do so organically, as we make other changes. I want it to be consistent. To claim that we're consistent about this in any way is laughable. vq ___ 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
Re: [129502] trunk/dports/security
On Dec 14, 2014, at 11:59 AM, khindenb...@macports.org wrote:
Revision
129502
Author
khindenb...@macports.org
Date
2014-12-14 09:59:07 -0800 (Sun, 14 Dec 2014)
Log Message
lastpass-cli: new port #45578 (and #45886)
Added Paths
• trunk/dports/security/lastpass-cli/
• trunk/dports/security/lastpass-cli/Portfile
Diff
Added: trunk/dports/security/lastpass-cli/Portfile (0 = 129502)
--- trunk/dports/security/lastpass-cli/Portfile
(rev 0)
+++ trunk/dports/security/lastpass-cli/Portfile 2014-12-14 17:59:07 UTC
(rev 129502)
@@ -0,0 +1,55 @@
+# # -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil;
c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
+# $Id$
+
+PortSystem 1.0
+PortGroup github 1.0
+
+github.setuplastpass lastpass-cli 0.4.0 v
+
+categories security
+platforms darwin
+maintainers gmail.com:israelchauca oaf.dk:mni khindenburg
openmaintainer
+license GPL-2
+supported_archs noarch
+
+description C99 command line interface to LastPass.com
I would remove C99 from the description; I don't think anyone reading the
description of a port cares what flavor of what programming language it was
written in.
+subport ${name}-pinentry {
+description-append using pinentry
+long_description-append using pinentry
+
+conflicts ${name}
+depends_lib-append port:pinentry
+}
This doesn't look sufficient. If pinentry support is automatically included
simply because pinentry is installed, then the main (non-pinentry) port needs
to be fixed not to use pinentry even if it is already installed.
Moreover, it seems strange to implement this as a subport instead of a variant.
Unless a subport is a -devel subport, it's not supposed to conflict with the
main port. Variants are typically used to enable optional features; pinentry
support thus seems like a natural fit for a variant. What is the implication of
having lastpass-cli built with pinentry support? I'm not really clear on what
pinentry is.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [129502] trunk/dports/security
On Dec 14, 2014, at 8:58 PM, Ryan Schmidt ryandes...@macports.org wrote: On Dec 14, 2014, at 11:59 AM, khindenb...@macports.org wrote: This doesn't look sufficient. If pinentry support is automatically included simply because pinentry is installed, then the main (non-pinentry) port needs to be fixed not to use pinentry even if it is already installed. Moreover, it seems strange to implement this as a subport instead of a variant. Unless a subport is a -devel subport, it's not supposed to conflict with the main port. Variants are typically used to enable optional features; pinentry support thus seems like a natural fit for a variant. What is the implication of having lastpass-cli built with pinentry support? I'm not really clear on what pinentry is. My fault - I was under the impression we didn’t want to use variants anymore. I’ll correct shortly. pinentry is gnupg’s way to enter pin/password via dialogs. Kurt ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [129502] trunk/dports/security
On Dec 14, 2014, at 8:48 PM, Kurt Hindenburg wrote: On Dec 14, 2014, at 8:58 PM, Ryan Schmidt wrote: Moreover, it seems strange to implement this as a subport instead of a variant. Unless a subport is a -devel subport, it's not supposed to conflict with the main port. Variants are typically used to enable optional features; pinentry support thus seems like a natural fit for a variant. What is the implication of having lastpass-cli built with pinentry support? I'm not really clear on what pinentry is. My fault - I was under the impression we didn’t want to use variants anymore. I’ll correct shortly. pinentry is gnupg’s way to enter pin/password via dialogs. Variants are still used, where appropriate. Enabling optional features of a program is an appropriate use of a variant, assuming there's good reason not to just always enable the feature. Installing optional documentation is an appropriate use of a subport. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [129502] trunk/dports/security
On 2014-12-15 13:48 , Kurt Hindenburg wrote: On Dec 14, 2014, at 8:58 PM, Ryan Schmidt ryandes...@macports.org wrote: On Dec 14, 2014, at 11:59 AM, khindenb...@macports.org wrote: This doesn't look sufficient. If pinentry support is automatically included simply because pinentry is installed, then the main (non-pinentry) port needs to be fixed not to use pinentry even if it is already installed. Moreover, it seems strange to implement this as a subport instead of a variant. Unless a subport is a -devel subport, it's not supposed to conflict with the main port. Variants are typically used to enable optional features; pinentry support thus seems like a natural fit for a variant. What is the implication of having lastpass-cli built with pinentry support? I'm not really clear on what pinentry is. My fault - I was under the impression we didn’t want to use variants anymore. I’ll correct shortly. pinentry is gnupg’s way to enter pin/password via dialogs. We don't want to use variants for things that other ports need to depend on. Variants are fine when there are no dependents or they're not affected by the chosen variants changing. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
remove @macports for no|openmaintainer
Hi, It seems that people often think nomaintai...@macports.org and openmaintai...@macports.org are real addresses. The attached patch doesn’t add the @macports.org on port’s info. What do people think? Kurt Maintainers: nomaintainer Maintainers: openmaintainer port.maintainer.diff Description: Binary data ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: remove @macports for no|openmaintainer
I don't see why not, although I'd prefer something simpler, like this.
vq
diff --git a/base/src/port/port.tcl b/base/src/port/port.tcl
index 76a53c9..f81f891 100644
--- a/base/src/port/port.tcl
+++ b/base/src/port/port.tcl
@@ -686,7 +686,7 @@ proc unobscure_maintainers { list } {
if {[string first @ $m] 0} {
if {[string first : $m] = 0} {
set m [regsub -- (.*):(.*) $m \\2@\\1]
-} else {
+} elseif {$m ne openmaintainer $m ne nomaintainer} {
set m $m...@macports.org
}
}
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [MacPorts] Migration modified
The migration steps weren't really intended to be run as a single script. I'm
not comfortable telling users to run this big untested blob of code.
On Dec 14, 2014, at 10:37 PM, MacPorts nore...@macports.org wrote:
Page Migration was changed by d...@yost.com
Diff URL: https://trac.macports.org/wiki/Migration?action=diffversion=80
Revision 80
Comment: Use a single sudo, so only one password is required.
Changes:
---8--8--8--8--8--8--8--8
Index: Migration
=
--- Migration (version: 79)
+++ Migration (version: 80)
@@ -23,29 +23,36 @@
{{{
# If there is an argument, then don't preserve 'requested' flags.
function reinstallPorts() {
- dontPreserveRequestedFlags=$1
+ local -r dontPreserveRequestedFlags=$1
+ set -e
+ # This will fail if xcode-select needs to be run.
+ clang --version
What is the point of printing the Clang version? And you don't know which
clang is being run.
vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Removing extraneous files on buildbots that block activation
I've seen a number of instances recently on the buildbots where a port fails on activation because of extraneous files left in the installation tree by some previous failure. My most recent example is py27-cython on buildports-snowleopard-x86_64: Error: org.macports.activate for port py27-cython returned: Image error: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/cygdb already exists and does not belong to a registered port. Unable to activate port py27-cython. Use 'port -f activate py27-cython' to force the activation. DEBUG: Error code: registry::image-error DEBUG: Backtrace: Image error: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/cygdb already exists and does not belong to a registered port. Unable to activate port py27-cython. Use 'port -f activate py27-cython' to force the activation. Typically this is occurs when the activation process is interrupted before completion and is fixed by manually forcing the activation and removing the offending file(s) that are moved aside in the process. Is there any way of fixing these problems on the buildbots as they occur (or maybe when the buildbot is restarted) without resorting to manual intervention by a sysadmin? Dave ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [MacPorts] Migration modified
On 2014-12-14, at 07:59 PM, Lawrence Velázquez lar...@macports.org wrote:
The migration steps weren't really intended to be run as a single script. I'm
not comfortable telling users to run this big untested blob of code.
Then let’s test it! Works for me on Yosemite. I’ll run it again.
You could put in a caveat that one can run the commands interactively if one is
worried about it.
Really, code to do a migration should be part of macports, IMO. Nothing like
being able to start a command and walk away for a couple of hours and have it
do everything without tweaking.
Dave
On Dec 14, 2014, at 10:37 PM, MacPorts nore...@macports.org wrote:
Page Migration was changed by d...@yost.com
Diff URL: https://trac.macports.org/wiki/Migration?action=diffversion=80
Revision 80
Comment: Use a single sudo, so only one password is required.
Changes:
---8--8--8--8--8--8--8--8
Index: Migration
=
--- Migration (version: 79)
+++ Migration (version: 80)
@@ -23,29 +23,36 @@
{{{
# If there is an argument, then don't preserve 'requested' flags.
function reinstallPorts() {
- dontPreserveRequestedFlags=$1
+ local -r dontPreserveRequestedFlags=$1
+ set -e
+ # This will fail if xcode-select needs to be run.
+ clang --version
What is the point of printing the Clang version? And you don't know which
clang is being run.
I was looking for a command I could run to smoke out wither code-select is
going to have to run before port can do its work.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Removing extraneous files on buildbots that block activation
On 2014-12-15 15:46 , David Evans wrote:
I've seen a number of instances recently on the buildbots where a port
fails on activation because of extraneous files left in the installation
tree by some previous failure.
My most recent example is py27-cython on buildports-snowleopard-x86_64:
Error: org.macports.activate for port py27-cython returned: Image error:
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/cygdb
already exists and does not belong to a registered port. Unable to activate
port py27-cython. Use 'port -f activate py27-cython' to force the activation.
DEBUG: Error code: registry::image-error
DEBUG: Backtrace: Image error:
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/cygdb
already exists and does not belong to a registered port. Unable to activate
port py27-cython. Use 'port -f activate py27-cython' to force the activation.
Typically this is occurs when the activation process is interrupted
before completion and is fixed by manually forcing the activation and
removing the offending file(s) that are moved aside in the process.
Is there any way of fixing these problems on the buildbots as they occur
(or maybe when the buildbot is restarted) without resorting to manual
intervention by a sysadmin?
This more commonly occurs because ports installed directly into $prefix
instead of into ${destroot}${prefix} (this is often caught by sandboxing
now.) So even if that's not what happened here, you could fix it the
same way.
- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Removing extraneous files on buildbots that block activation
On 12/14/14 8:57 PM, Joshua Root wrote:
On 2014-12-15 15:46 , David Evans wrote:
I've seen a number of instances recently on the buildbots where a port
fails on activation because of extraneous files left in the installation
tree by some previous failure.
My most recent example is py27-cython on buildports-snowleopard-x86_64:
Error: org.macports.activate for port py27-cython returned: Image error:
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/cygdb already
exists and does not belong to a registered port. Unable to activate port
py27-cython. Use 'port -f activate py27-cython' to force the activation.
DEBUG: Error code: registry::image-error
DEBUG: Backtrace: Image error:
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/cygdb already
exists and does not belong to a registered port. Unable to activate port
py27-cython. Use 'port -f activate py27-cython' to force the activation.
Typically this is occurs when the activation process is interrupted
before completion and is fixed by manually forcing the activation and
removing the offending file(s) that are moved aside in the process.
Is there any way of fixing these problems on the buildbots as they occur
(or maybe when the buildbot is restarted) without resorting to manual
intervention by a sysadmin?
This more commonly occurs because ports installed directly into $prefix
instead of into ${destroot}${prefix} (this is often caught by sandboxing
now.) So even if that's not what happened here, you could fix it the
same way.
- Josh
Yes, I've seen this occur as well but in this case, the offending port
correctly activates on the other buildbots (and on my local machine) so
I don't think there's anything to
fix in the port. In this case, my port of interest is py-poppler and
this dependency is breaking the build.
However this happens, once it does and even if the root cause in a port
is fixed, the problem will continue until the offending file is removed
and deactivating the port won't do it because it's seen as not belonging
to a registered port. I don't see anyway to remove the offending file
on the buildbot without doing so manually and most folks don't have the
access to do it. So do we queue a request to the sysadmins when this
occurs or is there some other way to deal with it that I'm not thinking of?
Dave
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Removing extraneous files on buildbots that block activation
On 2014-12-15 16:25 , David Evans wrote:
On 12/14/14 8:57 PM, Joshua Root wrote:
On 2014-12-15 15:46 , David Evans wrote:
I've seen a number of instances recently on the buildbots where a port
fails on activation because of extraneous files left in the installation
tree by some previous failure.
My most recent example is py27-cython on buildports-snowleopard-x86_64:
Error: org.macports.activate for port py27-cython returned: Image
error:
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/cygdb
already
exists and does not belong to a registered port. Unable to activate
port py27-cython. Use 'port -f activate py27-cython' to force the
activation.
DEBUG: Error code: registry::image-error
DEBUG: Backtrace: Image error:
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/cygdb
already
exists and does not belong to a registered port. Unable to activate
port py27-cython. Use 'port -f activate py27-cython' to force the
activation.
Typically this is occurs when the activation process is interrupted
before completion and is fixed by manually forcing the activation and
removing the offending file(s) that are moved aside in the process.
Is there any way of fixing these problems on the buildbots as they occur
(or maybe when the buildbot is restarted) without resorting to manual
intervention by a sysadmin?
This more commonly occurs because ports installed directly into $prefix
instead of into ${destroot}${prefix} (this is often caught by sandboxing
now.) So even if that's not what happened here, you could fix it the
same way.
- Josh
Yes, I've seen this occur as well but in this case, the offending port
correctly activates on the other buildbots (and on my local machine) so
I don't think there's anything to
fix in the port. In this case, my port of interest is py-poppler and
this dependency is breaking the build.
However this happens, once it does and even if the root cause in a port
is fixed, the problem will continue until the offending file is removed
and deactivating the port won't do it because it's seen as not belonging
to a registered port. I don't see anyway to remove the offending file
on the buildbot without doing so manually and most folks don't have the
access to do it. So do we queue a request to the sysadmins when this
occurs or is there some other way to deal with it that I'm not thinking of?
This is the same way that I was referring to:
https://lists.macosforge.org/pipermail/macports-dev/2014-November/028621.html
- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Removing extraneous files on buildbots that block activation
On 12/14/14 9:56 PM, Joshua Root wrote:
On 2014-12-15 16:25 , David Evans wrote:
On 12/14/14 8:57 PM, Joshua Root wrote:
On 2014-12-15 15:46 , David Evans wrote:
I've seen a number of instances recently on the buildbots where a port
fails on activation because of extraneous files left in the installation
tree by some previous failure.
My most recent example is py27-cython on buildports-snowleopard-x86_64:
Error: org.macports.activate for port py27-cython returned: Image
error:
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/cygdb already
exists and does not belong to a registered port. Unable to activate
port py27-cython. Use 'port -f activate py27-cython' to force the
activation.
DEBUG: Error code: registry::image-error
DEBUG: Backtrace: Image error:
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/cygdb already
exists and does not belong to a registered port. Unable to activate
port py27-cython. Use 'port -f activate py27-cython' to force the
activation.
Typically this is occurs when the activation process is interrupted
before completion and is fixed by manually forcing the activation and
removing the offending file(s) that are moved aside in the process.
Is there any way of fixing these problems on the buildbots as they occur
(or maybe when the buildbot is restarted) without resorting to manual
intervention by a sysadmin?
This more commonly occurs because ports installed directly into $prefix
instead of into ${destroot}${prefix} (this is often caught by sandboxing
now.) So even if that's not what happened here, you could fix it the
same way.
- Josh
Yes, I've seen this occur as well but in this case, the offending port
correctly activates on the other buildbots (and on my local machine) so
I don't think there's anything to
fix in the port. In this case, my port of interest is py-poppler and
this dependency is breaking the build.
However this happens, once it does and even if the root cause in a port
is fixed, the problem will continue until the offending file is removed
and deactivating the port won't do it because it's seen as not belonging
to a registered port. I don't see anyway to remove the offending file
on the buildbot without doing so manually and most folks don't have the
access to do it. So do we queue a request to the sysadmins when this
occurs or is there some other way to deal with it that I'm not thinking of?
This is the same way that I was referring to:
https://lists.macosforge.org/pipermail/macports-dev/2014-November/028621.html
- Josh
Thanks for this reference but I think you and are not on the same page
here somehow.
I don't think that the problem here was caused by py27-cython but by
some transient failure on just one buildbot. So once the offending file
or files are removed, I don't expect to see this happen again. If my
theory is correct it doesn't seem appropriate to add code to py-cython
that is only needed for one build.
I was thinking more along the lines of adding a cleanup script somewhere
in the buildbot build script that scans the install tree and deletes
extraneous files at a point when all installed ports are deactivated.
Dave
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Removing extraneous files on buildbots that block activation
On Mon, Dec 15, 2014 at 8:32 AM, David Evans wrote: If my theory is correct it doesn't seem appropriate to add code to py-cython that is only needed for one build. You could just as well add code, wait for the build on the buildbot to finish and remove the code again. It's a quick-and-dirty patch for sure, but it doesn't hurt if you only leave it there for a short while. Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
