On Oct 2, 2014, at 12:59 AM, ryandes...@macports.org wrote:
> Revision
> 126021
> Author
> ryandes...@macports.org
> Date
> 2014-10-01 22:59:21 -0700 (Wed, 01 Oct 2014)
> Log Message
>
> gr1c: new port, version 0.6.2 (#41653)
> Added Paths
>
> • trunk/dports/math/gr1c/
> • trunk/dpor
> On Oct 1, 2014, at 4:10 PM, pixi...@macports.org wrote:
>
> Revision
> 126005
> Author
> pixi...@macports.org
> Date
> 2014-10-01 14:10:50 -0700 (Wed, 01 Oct 2014)
> Log Message
>
> mail/dovecot2:
> - Replace hardcoded /opt/local the $prefix.
> - Remove trailing whitespace.
>
> Modified Paths
On Oct 1, 2014, at 1:59 PM, Bradley Giesbrecht wrote:
>
> On Oct 1, 2014, at 1:10 PM, Lawrence Velázquez wrote:
>
>> On Sep 16, 2014, at 5:22 PM, Ryan Schmidt wrote:
>>
>>> The problem with dots in port names is that so far "port lint" has declared
>>> the dot an illegal character in a var
On Oct 1, 2014, at 1:10 PM, Lawrence Velázquez wrote:
> On Sep 16, 2014, at 5:22 PM, Ryan Schmidt wrote:
>
>> The problem with dots in port names is that so far "port lint" has declared
>> the dot an illegal character in a variant name. This has led the perl5 port
>> for example to adopt var
On Oct 1, 2014, at 2:47 PM, Ryan Schmidt wrote:
>
>> On Oct 1, 2014, at 2:02 PM, m...@macports.org wrote:
>>
>> Revision
>> 125999
>> Author
>> m...@macports.org
>> Date
>> 2014-10-01 12:02:07 -0700 (Wed, 01 Oct 2014)
>> Log Message
>>
>> ifeffit: Only use gcc for FORTRAN. (#44631)
>> Modifie
> On Oct 1, 2014, at 2:02 PM, m...@macports.org wrote:
>
> Revision
> 125999
> Author
> m...@macports.org
> Date
> 2014-10-01 12:02:07 -0700 (Wed, 01 Oct 2014)
> Log Message
>
> ifeffit: Only use gcc for FORTRAN. (#44631)
> Modified Paths
>
> • trunk/dports/science/ifeffit/Portfile
>
>
On Sep 16, 2014, at 5:22 PM, Ryan Schmidt wrote:
> The problem with dots in port names is that so far "port lint" has declared
> the dot an illegal character in a variant name. This has led the perl5 port
> for example to adopt variant names like perl5_16 which I've always found a
> little con
On Oct 1, 2014, at 3:30 PM, Sean Farley wrote:
> Lawrence Velázquez writes:
>
>> Except that base automatically adds dependencies on `gccXY` depending on
>> configure.compiler, so renaming them requires some sort of migration
>> strategy. Either we wait until a new MacPorts release, or we jury
Lawrence Velázquez writes:
> Resurrecting this thread. Let's keep general renaming discussion here.
Sure, sounds good.
> On Sep 16, 2014, at 5:22 PM, Ryan Schmidt wrote:
>
>> It's been proposed on this list that we should rename MySQL ports e.g.
>> mysql51 -> mysql-5.1; this would be to match
Frank Schima writes:
> On Oct 1, 2014, at 12:26 PM, Sean Farley wrote:
>
>> Ryan Schmidt writes:
>>
>>> On Oct 1, 2014, at 12:48 PM, Sean Farley wrote:
>>>
Proposal:
Since it seems that we are flat-out disallowing gcc being used as a
C/C++ compiler, I think it's time to do
Resurrecting this thread. Let's keep general renaming discussion here.
On Sep 16, 2014, at 5:22 PM, Ryan Schmidt wrote:
> It's been proposed on this list that we should rename MySQL ports e.g.
> mysql51 -> mysql-5.1; this would be to match the existing new ports
> mariadb-10.0 and mariadb-10.1
Lawrence Velázquez writes:
> On Oct 1, 2014, at 3:08 PM, Frank Schima wrote:
>
>> On Oct 1, 2014, at 12:26 PM, Sean Farley wrote:
>>
>>> We really should be consistent then. I personally don't care what the
>>> new name is but we should either have clangX.Y / gccX.Y or clangXY /
>>> gccXY.
>>
On Oct 1, 2014, at 3:08 PM, Frank Schima wrote:
> On Oct 1, 2014, at 12:26 PM, Sean Farley wrote:
>
>> We really should be consistent then. I personally don't care what the
>> new name is but we should either have clangX.Y / gccX.Y or clangXY /
>> gccXY.
>
> I say we use gccX.Y. Just renaming
On Oct 1, 2014, at 12:26 PM, Sean Farley wrote:
> Ryan Schmidt writes:
>
>> On Oct 1, 2014, at 12:48 PM, Sean Farley wrote:
>>
>>> Proposal:
>>>
>>> Since it seems that we are flat-out disallowing gcc being used as a
>>> C/C++ compiler, I think it's time to do some clean up of the code:
>>>
Bradley Giesbrecht writes:
> On Oct 1, 2014, at 10:58 AM, Sean Farley wrote:
>
>> As discussed in the MPI thread, PPC is very old and is causing quite the
>> development burden. I would be in favor of discussing how much effort we
>> really want to spend supporting them (similar to supporting li
Ryan Schmidt writes:
> On Oct 1, 2014, at 12:48 PM, Sean Farley wrote:
>
>> Proposal:
>>
>> Since it seems that we are flat-out disallowing gcc being used as a
>> C/C++ compiler, I think it's time to do some clean up of the code:
>>
>> 1) Rename gccXY to gcc-X.Y
>
> As I proposed earlier, we mi
On Oct 1, 2014, at 10:58 AM, Sean Farley wrote:
> As discussed in the MPI thread, PPC is very old and is causing quite the
> development burden. I would be in favor of discussing how much effort we
> really want to spend supporting them (similar to supporting libstdc++ on
> Mavericks).
>
> We c
On Oct 1, 2014, at 12:48 PM, Sean Farley wrote:
> Proposal:
>
> Since it seems that we are flat-out disallowing gcc being used as a
> C/C++ compiler, I think it's time to do some clean up of the code:
>
> 1) Rename gccXY to gcc-X.Y
As I proposed earlier, we might want to avoid using a dash in
On Oct 1, 2014, at 6:45 AM, Craig Treleaven wrote:
> At 3:07 PM -0500 9/30/14, Ryan Schmidt wrote:
>> Currently, the latest stable version of MariaDB is 10.0.
>
> Really?
Yes, in that MariaDB 10.0 is the latest "release" version.
> Has MariaDB 10.0 really been sufficiently exercised in the
>
On Oct 1, 2014, at 12:01 PM, Daniel J. Luke wrote:
> On Oct 1, 2014, at 1:58 PM, Sean Farley wrote:
>>
>> As discussed in the MPI thread, PPC is very old and is causing quite the
>> development burden. I would be in favor of discussing how much effort we
>> really want to spend supporting them
On Oct 1, 2014, at 1:58 PM, Sean Farley wrote:
>
> As discussed in the MPI thread, PPC is very old and is causing quite the
> development burden. I would be in favor of discussing how much effort we
> really want to spend supporting them (similar to supporting libstdc++ on
> Mavericks).
>
> We c
Daniel J. Luke writes:
> On Oct 1, 2014, at 1:36 PM, Brandon Allbery wrote:
>>
>> On Wed, Oct 1, 2014 at 1:30 PM, Sean Farley 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.
As discussed in the MPI thread, PPC is very old and is causing quite the
development burden. I would be in favor of discussing how much effort we
really want to spend supporting them (similar to supporting libstdc++ on
Mavericks).
We could tag some known version of the MacPorts svn tree for PPC us
Proposal:
Since it seems that we are flat-out disallowing gcc being used as a
C/C++ compiler, I think it's time to do some clean up of the code:
1) Rename gccXY to gcc-X.Y
2) Rename +gccXY variants to +gfortranXY
3) Start moving away from configure.compiler=macports-gcc*
I think it's important
On Oct 1, 2014, at 1:36 PM, Brandon Allbery wrote:
>
> On Wed, Oct 1, 2014 at 1:30 PM, Sean Farley 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 don't think any apple-provided OS
On Wed, Oct 1, 2014 at 1:30 PM, Sean Farley 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 10.8/10.9; in an
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 b
Ryan Schmidt writes:
> 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 d
At 3:07 PM -0500 9/30/14, Ryan Schmidt wrote:
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
> 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
30 matches
Mail list logo
