Re: mpi

On Oct 1, 2014, at 12:23 AM, Sean Farley wrote: > Ryan Schmidt writes: > >> On Sep 30, 2014, at 11:25 PM, Sean Farley wrote: >>> >>> Ryan Schmidt writes: >>> On Sep 30, 2014, at 10:48 PM, Sean Farley wrote: > > Variants create a new node in the dependency DAG. Subports create a n

Re: mpi

Ryan Schmidt writes: > On Sep 30, 2014, at 11:25 PM, Sean Farley wrote: >> >> Ryan Schmidt writes: >> >>> On Sep 30, 2014, at 10:48 PM, Sean Farley wrote: Variants create a new node in the dependency DAG. Subports create a new node in the dependency DAG. There is no topological

Re: mpi

On Sep 30, 2014, at 11:25 PM, Sean Farley wrote: > > Ryan Schmidt writes: > >> On Sep 30, 2014, at 10:48 PM, Sean Farley wrote: >>> >>> Variants create a new node in the dependency DAG. Subports create a new >>> node in the dependency DAG. There is no topological difference. The only >>> differe

Re: mpi

Ryan Schmidt writes: > 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 imple

Re: mpi

On Wed, Oct 1, 2014 at 12:16 AM, Ryan Schmidt wrote: > > Said mismatch issues didn't exist until Apple switched the default > compiler to clang and default runtime to libc++, in 10.9. In particular, > while clang was the default compiler on 10.8, libstdc++ was still the > default runtime; it was

Re: mpi

On Sep 30, 2014, at 11:10 PM, Brandon Allbery wrote: > > On Wed, Oct 1, 2014 at 12:04 AM, Ryan Schmidt 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

Re: mpi

On Wed, Oct 1, 2014 at 12:04 AM, Ryan Schmidt 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 default runtime to libc++, i

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 gre

Re: [123602] trunk/dports/python/py-astropy/Portfile

Ryan Schmidt writes: >> That sounds right. What I'm attempting to improve (or, rather, stir up >> awareness) are the many steps that are manual. Being that stealth >> updates are infrequent, I usually forgot to check for them. I think >> >> A workflow I am trying to strive for (which maybe shou

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.

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

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. S

Re: mpi

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 clearly (to me, at least) an antipattern (using

Re: [123602] trunk/dports/python/py-astropy/Portfile

> On Sep 30, 2014, at 8:55 PM, Sean Farley wrote: > > > Ryan Schmidt writes: > * It assumes the port's revision will be increased. That's not always necessary. Sometimes the only change in the distfile is the name of (or presence of) the enclosing directory, or there are only c

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

Re: mpi

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 clearly (to me, at least) an antipattern (using variants to select build options). v

Re: mpi

> On Sep 30, 2014, at 9:44 PM, Lawrence Velázquez wrote: > > On Sep 30, 2014, at 10:09 PM, Ryan Schmidt 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

Re: mpi

On Sep 30, 2014, at 10:09 PM, Ryan Schmidt 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 can'

Re: mpi

Brandon Allbery writes: > On Tue, Sep 30, 2014 at 10:08 PM, Sean Farley wrote: > >> Why can't all a port's variants be installed at the same time? > > > This wouldn't solve problems like, if you get anywhere near any of the > Apple C++ frameworks, you just lost the ability to use g++ in any way,

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 ins

Re: OT: sed/awk pointers needed

At 2:27 PM -0400 9/30/14, Lawrence Velázquez wrote: On Sep 30, 2014, at 12:00 PM, Brandon Allbery wrote: > On Tue, Sep 30, 2014 at 11:44 AM, Craig Treleaven wrote: >> I have only rudimentary acquaintance with sed and less with awk. I'd like to learn more and this seemed like an opportunit

Re: mpi

On Tue, Sep 30, 2014 at 10:08 PM, Sean Farley wrote: > Why can't all a port's variants be installed at the same time? This wouldn't solve problems like, if you get anywhere near any of the Apple C++ frameworks, you just lost the ability to use g++ in any way, shape, or form on 10.9. -- brando

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? > > $ p

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 ab

Re: [123602] trunk/dports/python/py-astropy/Portfile

Ryan Schmidt writes: >>> * It assumes the port's revision will be increased. That's not always >>> necessary. Sometimes the only change in the distfile is the name of (or >>> presence of) the enclosing directory, or there are only changes in comments >>> or documentation files or other files t

Re: OT: sed/awk pointers needed

On Sep 30, 2014, at 4:02 PM, Craig Treleaven wrote: > you've given me a complete solution! I just realized that you're probably using "N" to signify that a variant is not selected, so "Y" should be used if a variant *is* selected. # Save port to hold space. / has the variants/ { s/ has .*

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

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 C/C++/

Re: [123602] trunk/dports/python/py-astropy/Portfile

On Sep 30, 2014, at 7:26 PM, Sean Farley wrote: > > Ryan Schmidt writes: > >> On Sep 30, 2014, at 4:55 PM, Sean Farley wrote: >> >>> As for this exact issue, it could be something as simple as a fallback >>> test: >>> >>> if checksum doesn't match and revision is new: >>> try downloading again

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 w

Re: [123602] trunk/dports/python/py-astropy/Portfile

Ryan Schmidt writes: > On Sep 30, 2014, at 4:55 PM, Sean Farley wrote: > >> As for this exact issue, it could be something as simple as a fallback >> test: >> >> if checksum doesn't match and revision is new: >> try downloading again >> write state so we don't download in an infinite loop > >

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' variabl

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 c

Re: [123602] trunk/dports/python/py-astropy/Portfile

On Sep 30, 2014, at 4:55 PM, Sean Farley wrote: > As for this exact issue, it could be something as simple as a fallback > test: > > if checksum doesn't match and revision is new: > try downloading again > write state so we don't download in an infinite loop That's a conceivable change. But l

Re: [123602] trunk/dports/python/py-astropy/Portfile

Daniel J. Luke writes: > On Aug 12, 2014, at 11:11 AM, Ryan Schmidt wrote: >> >> It's still not totally automatic: the developer still has to update the >> checksums, so if the developer is sufficiently aware that the checksums need >> to be updated, why can't the developer also follow the st

Re: mpi

Ryan Schmidt writes: > We've had multiple bug reports from users who had installed boost with one of > the gcc variants. Either the build failed when using those variants, or the > build of boost succeeded but then the build of another port that depends on > boost failed. We attributed this to

Re: MacPorts-MySQL Dictator wanted, prefer benevolent

On Tue, Sep 30, 2014 at 5:02 PM, Bradley Giesbrecht wrote: > > That's where the dictator comes in. At the moment, I would say the > obvious choices for a default MySQL variant would be mysql55, mariadb55 or, > maybe, mysql56. AFAICT there is no clear-cut, compelling reason to choose > one over

Re: MacPorts-MySQL Dictator wanted, prefer benevolent

On Sep 30, 2014, at 8:37 AM, Craig Treleaven wrote: > By way of background, my MythTV ports depend on p5.16-dbd-mysql, py27-mysql > and php-5-mysql. Previously, all of these defaulted to the now-obsolete > mysql5 variant. Now, py-mysql defaults to mariadb55. p516-dbd-mysql offers > a "mari

Re: MacPorts-MySQL Dictator wanted, prefer benevolent

On Sep 30, 2014, at 10:37 AM, Craig Treleaven wrote: > By way of background, my MythTV ports depend on p5.16-dbd-mysql, py27-mysql > and php-5-mysql. Previously, all of these defaulted to the now-obsolete > mysql5 variant. Now, py-mysql defaults to mariadb55. p516-dbd-mysql offers > a "mari

Re: OT: sed/awk pointers needed

At 2:27 PM -0400 9/30/14, Lawrence Velázquez wrote: On Sep 30, 2014, at 12:00 PM, Brandon Allbery wrote: On Tue, Sep 30, 2014 at 11:44 AM, Craig Treleaven wrote: I have only rudimentary acquaintance with sed and less with awk. I'd like to learn more and this seemed like an opportunity to

Re: [125934] trunk/dports/mail

On Sep 30, 2014, at 11:13 AM, Bradley Giesbrecht wrote: > On Sep 29, 2014, at 7:38 PM, Ryan Schmidt wrote: > >> I presume this is noarch? > > Yes. While I was writing this Portfile I wished that we had a Portfile > creation script that would prompt for input of the most important Portfile > k

Re: nginx port

Hi, - On 30 Sep, 2014, at 11:16, Ivan Larionov xeron.os...@gmail.com wrote: > https://trac.macports.org/changeset/125927 > > How you can say it’s not “unstable” if 2 modules doesn’t work at all? Upstream no longer calls it unstable and recommends using mainline rather than stable: "Note th

Re: OT: sed/awk pointers needed

On Sep 30, 2014, at 12:00 PM, Brandon Allbery wrote: > On Tue, Sep 30, 2014 at 11:44 AM, Craig Treleaven > wrote: >> I have only rudimentary acquaintance with sed and less with awk. I'd like >> to learn more and this seemed like an opportunity to do so. From some >> reading [1], I think sed'

Re: [125934] trunk/dports/mail

On Sep 29, 2014, at 7:38 PM, Ryan Schmidt wrote: > I presume this is noarch? Yes. While I was writing this Portfile I wished that we had a Portfile creation script that would prompt for input of the most important Portfile keywords. I'll add supported_archs noarch. > Remember you'll have to us

Re: OT: sed/awk pointers needed

On Tue, Sep 30, 2014 at 11:44 AM, Craig Treleaven wrote: > I have only rudimentary acquaintance with sed and less with awk. I'd like > to learn more and this seemed like an opportunity to do so. From some > reading [1], I think sed's Hold buffer is the way to extract the port name > and insert i

OT: sed/awk pointers needed

tl;dr version: How do I transform a listing like this: $ port variants php53-mysql php54-mysql |grep -v conflicts |grep -e mariadb -e mysql -e percona | cut -d : -f 1 php53-mysql has the variants mariadb mysql4 mysql5 mysql51 mysql55 mysql56 [+]mysqlnd percona php54-mysql h

MacPorts-MySQL Dictator wanted, prefer benevolent

By way of background, my MythTV ports depend on p5.16-dbd-mysql, py27-mysql and php-5-mysql. Previously, all of these defaulted to the now-obsolete mysql5 variant. Now, py-mysql defaults to mariadb55. p516-dbd-mysql offers a "mariadb" variant; not "mariadb55". php5-mysql defaults to mysqlin

Re: [125841] trunk/dports/games/crafty/Portfile

On 9/27/14, 11:07 PM, Joshua Root wrote: Revision: 125841 https://trac.macports.org/changeset/125841 Author: khindenburg at macports.org Date: 2014-09-27 07:32:31 -0700 (Sat, 27 Sep 2014) Log Message: --- crafty: add license (Unknown) Modified Paths: --

Re: Calligra and Koffice [was: imake]

On Tue, Sep 30, 2014 at 5:46 AM, Nicolas Pavillon wrote: > Apart from the possibility of announcing calligra as a replacement of > koffice, I am nevertheless hesitating about committing the existing > portfile. It can build, so that it would be a good starting point to > improve on, but on the ot

Re: Calligra and Koffice [was: imake]

Hello, > As Ryan said, it is not really the duty of MacPorts developers to keep > ports alive if they are not supported upstream. KDE 3 is long since > "dead" (unmaintained) and all KDE apps dependent on KDE 3 with it. > So, do not worry about KOffice… :-( You have a fair point here. I’ll proce

nginx port

https://trac.macports.org/changeset/125927 How you can say it’s not “unstable” if 2 modules doesn’t work at all? May be it’s better to have 2 different ports, like nginx and nginx-devel? -- With best regards, Ivan Larionov. __

mpi

We've had multiple bug reports from users who had installed boost with one of the gcc variants. Either the build failed when using those variants, or the build of boost succeeded but then the build of another port that depends on boost failed. We attributed this to the mixing of C++ runtimes on