Re: gcc, AVX (and newer) intrinsics and binutils

> Either way, benchmarks like these are rarely representative of real-world > performance in *[y]our* workloads. My own experience over the years has been > that GCC gives measurably better performance and that in cases where every > last > drop doesn't count you were better off using clang be

Re: How to keep uncommitted work in a git clone

n 5 Nov 2016, at 10:34 am, Christopher Jones > wrote: > > > Hi, > > I did the svn->git translation myself at work in the recent past and went > through exactly the same things as you are now. Git and Svn are very > different in some regards and workflows that worked

Re: How to keep uncommitted work in a git clone

Hi, I did the svn->git translation myself at work in the recent past and went through exactly the same things as you are now. Git and Svn are very different in some regards and workflows that worked with svn simply do not with git. The ‘make all changes on master and commit only what I want ea

Re: New project members: jonesc

Thanks All ! > On 2 Nov 2016, at 7:07 pm, Lawrence Velázquez wrote: > >> On Nov 2, 2016, at 2:20 PM, Rainer Müller wrote: >> >> Please join us in welcoming the following new MacPorts project member: >> >> - Chris Jones (jonesc) >> >> We look forward to continued excellent contributions! >

Re: Issues with oudated ports / GitHub

> On 7 Oct 2016, at 8:12 pm, Ryan Schmidt wrote: > > >> On Oct 7, 2016, at 1:40 PM, Lawrence Velázquez wrote: >> >>> On Oct 7, 2016, at 2:09 PM, Chris Jones wrote: >>> >>> Currently, once they find out about svn, and trac >> >> We will still use Trac for issue tracking, although I believe

Re: Issues with oudated ports / GitHub

> On 7 Oct 2016, at 8:08 pm, Lawrence Velázquez wrote: > >> On Oct 7, 2016, at 2:58 PM, Christopher Jones >> wrote: >> >>> On 7 Oct 2016, at 7:40 pm, Lawrence Velázquez wrote: >>> >>>> On Oct 7, 2016, at 2:09 PM, Chris Jones wrote: &

Re: Issues with oudated ports / GitHub

> On 7 Oct 2016, at 7:40 pm, Lawrence Velázquez wrote: > >> On Oct 7, 2016, at 2:09 PM, Chris Jones wrote: >> >> Currently, once they find out about svn, and trac > > We will still use Trac for issue tracking, although I believe someone is > looking into integrating GitHub sign in. Personall

Re: Issues with oudated ports / GitHub

> On 7 Oct 2016, at 7:38 pm, Daniel J. Luke wrote: > > On Oct 7, 2016, at 2:09 PM, Chris Jones wrote: >>> moving to GitHub doesn't magically make more interested parties make >>> quality contributions. >> >> I agree that moving to github is not going to suddenly make people where not >> not

Re: No Xcode 8 CLT for El Capitan

> > > A user just added a comment to the cmake issue that indicates that it is > actually an undeclared type in the Apple header file, and that a bug report > has now been filed with Apple. It also includes a work around: > https://trac.macports.org/ticket/52258#comment:13 >

Re: llvm-3.9 "new libstdc++ ABI compatibility"

> On 2 Sep 2016, at 7:41 pm, René J.V. Bertin wrote: > > On Friday September 02 2016 13:45:56 Lawrence Velázquez wrote: > >>> Or is it something that will in fact mostly/only benefit Linux users? >> >> Yes. This is meant to keep Clang compatible with ABI changes to GCC 5.1's >> libstdc++. >

Re: How to discontinue ports completely (py26 deprecation) ...

> On 12 Aug 2016, at 11:30 pm, Fred Wright wrote: > > > On Fri, 12 Aug 2016, Chris Jones wrote: >> On 11/08/16 20:40, Fred Wright wrote: > [...] >>> Well, leaving something alone that's working just fine is hardly much of a >>> maintenance burden. >> >> On the other hand, whats the rationale f

Re: variants

> On 12 Apr 2016, at 8:50 pm, Daniel J. Luke wrote: > > On Apr 12, 2016, at 3:04 PM, Christopher Jones > wrote: >>> How do other package managers (that don't have variants) deal with ROOT6? >> >> I guess they have to decide a set of options that most

Re: variants

Hi, > On 12 Apr 2016, at 7:56 pm, Daniel J. Luke wrote: > > On Apr 12, 2016, at 2:52 PM, Christopher Jones > wrote: >>>> Some of them create additional libraries for the new features, some just >>>> add the functionality to existing ones. Most will also e

Re: variants

> On 12 Apr 2016, at 7:49 pm, Daniel J. Luke wrote: > > On Apr 12, 2016, at 1:34 PM, Christopher Jones > wrote: >> Take if you want, as a real world case, ROOT6, which I know well. It has a >> large number of variants, because upstream’s build system offers all thes

Re: variants

> On 12 Apr 2016, at 4:59 pm, Daniel J. Luke wrote: > > On Apr 12, 2016, at 11:49 AM, Chris Jones wrote: >> A lot of projects simply aren't built in a way that would allow that. The >> whole package (library, whatever) needs to be configured once with all the >> options, and built once. sub p

Re: PortGroup directory hierarchy/priority

> On 2 Apr 2016, at 7:48 pm, René J.V. Bertin wrote: > > On Saturday April 02 2016 19:27:38 Rainer Müller wrote: > >> This is not in any way slower than rsync. With no actual changes, a > > Maybe not if you do it very regularly. That quickly changes once you start > increasing the intervals,

Re: New Mac OS Forge administrator

> On 20 Nov 2015, at 8:15 p.m., Bradley Giesbrecht wrote: > >> On Nov 19, 2015, at 6:49 PM, Ryan Schmidt wrote: >> >> Dear MacPorts users and developers, >> >> I'm pleased finally to be able to tell you that I have been hired to be your >> new Mac OS Forge administrator. I have been involved

Re: Showing the full ./configure command also with -v, not just with -d

> On 30 Oct 2015, at 16:41, Sean Farley wrote: > > > Mojca Miklavec mailto:mo...@macports.org>> writes: > >> Hi, >> >> I would really appreciate it if I could see the complete configure >> command already in verbose mode (port -v configure), not just debug >> mode (port -d configure). The sam

Re: libexec vs lib

Your question suggests you don’t really understand what lib and libexec are for. They serve rather different purposes. There are plenty of resources on the web explaining the difference. > On 19 Sep 2015, at 5:16pm, Andrew L. Moore wrote: > > Guys, > Macports appears to install qt5-mac, llvm-3

Re: Changing port group default options

Hi, > In my opinion increasing the version of the portgroup should be > reserved for (fundamentally) incompatible changes or when the syntax > changes. (For example when switching from qt4 to qt5 if the portgroup > would initially be just "qt". Or if the python PortGroup would start > working for

Re: Current best practice to select GCC compiler in Portfile

The best practise is not to do it, unless it is for non C++ code (C, fortran, ..), as using gcc for C++ will lead to C++ runtime issues if the binaries you produce are used with others that where produced using clang, which like it or not is now the default OS X compiler. > On 26 Feb 2015, at 1

Checking for C++ runtime link mis-matches ?

Hi, Does MacPorts now check for linking c++ runtime mis-matches, i.e. when one library using one runtime, libc++ say, links against another using an incompatible runtime, libstdc++ ? I seem to recall an email discussion on this, but cannot find it or recall the details. Perhaps I made it up..

Re: OCE X11/XQuartz dependency

On 23 Jun 2014, at 1:04am, Mark Brethen wrote: > OCE depends on X11/XQuartz. What commands are needed to check if it has been > installed? Don’t. The OCE port should not use (by which I mean link against) any third party X11 libraries, but instead declare a dependency against the MacPorts one

Re: Update ticket - xrootd

Mucho gracias … On 20 May 2014, at 4:04pm, Frank Schima wrote: > Hi Chris, > > > Done in r120250 [1]. > > > Cheers! > Frank > > [1] <https://trac.macports.org/changeset/120250> > > On May 20, 2014, at 1:14 AM, Christopher Jones > wrote:

Update ticket - xrootd

Hi, Could someone please take a look at and commit https://trac.macports.org/ticket/43743 thanks in advance Chris smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.maco

Buildbot failure for new ROOT ports

Hi, Could someone explain the reason for the failure in step 8 of The only thing I can see indicating a problem is in dir /var/buildbot/ports-slave/buildports-mavericks-x86_64/build (timeout 1200 secs) What is step

Re: Building clang/cling 3.5 for ROOT on Lion

p.s. whats the most recent MacPorts clang compiler you can install on OSX10.7 ? On 8 Apr 2014, at 12:03am, Christopher Jones wrote: > Hi, > > For me, I’m afraid, I think this means ROOT6 can only be properly supported > on 10.8 or newer. As its only these OS versions that have c

Re: Building clang/cling 3.5 for ROOT on Lion

Hi, For me, I’m afraid, I think this means ROOT6 can only be properly supported on 10.8 or newer. As its only these OS versions that have c++11 support. If upstream have decided ROOT from version 6 onwards requires c++11 support, I am not going to second guess them. I previously had variants i

Re: [116514] trunk/base/src

> >>> of course, you are right, it should be changed to >>> >>> -if {$macosx_version == "10.5"} { >>> +if {$macosx_version eq "10.5"} { > > Nonetheless: http://trac.macports.org/changeset/116781. Th change to trunk/base/src/port1.0/portstartupitem.tcl looks suspicious -

Re: C++11 on Mountain Lion and lower?

Hi, On 3 Dec 2013, at 11:43pm, Ryan Schmidt wrote: > > On Dec 3, 2013, at 16:23, Christopher Jones wrote: > >> Part of the problem, for me, is MacPorts insists on all OSX versions using >> the same set of port versions. There is no way, I think, of having different >

Re: C++11 on Mountain Lion and lower?

Hi, On 3 Dec 2013, at 9:55pm, Ryan Schmidt wrote: > > On Dec 3, 2013, at 13:48, Christopher Jones wrote: > >> For that last one, it is not necessary to have Apple make that decision. >> macPorts could decide to release the current trunk, and force the use of >> l

Re: C++11 on Mountain Lion and lower?

Hi, On 3 Dec 2013, at 8:13pm, Clemens Lang wrote: > On Tue, Dec 03, 2013 at 07:48:48PM +0000, Christopher Jones wrote: >> For that last one, it is not necessary to have Apple make that >> decision. macPorts could decide to release the current trunk, and >> force the use

Re: C++11 on Mountain Lion and lower?

Hi, > Under the constraints we have I think its the best solution possible. > Alternatives would be > > - Mark the port as broken on systems < darwin13 :( > - Build a private copy of all dependencies of rethinkdb against > macports libstdc++. Since that includes boost and a couple of other >

Re: C++11 on Mountain Lion and lower?

Hi, > To follow up: the ML buildbot just succeeded building rethinkdb using > FSF GCC 4.8 (obviously using MacPorts libstdc++). I guess the binaries > will now use both > - /opt/local/lib/libstdc++.dylib and > - /usr/lib/libstdc++.dylib, > but I suppose that will cause a lot less problems than m

Re: 10.9 and compiler

>>> >>> >>> Can we not use blacklists on 10.9? Do we need to always use clang? Or is >>> that only for C++ code that we have to use clang? >> >> On 10.9, clang is the only system compiler. So for OSX 10.9, you need to use >> clang, for C C++, Obj-C etc. > > Thanks. Technically, one could u

Re: 10.9 and compiler

On 17 Nov 2013, at 9:07pm, Blair Zajac wrote: > I just got a new MacBook Pro and is the first machine I have access to that > can run 10.9, so I’m running into problems with fwknop-client port getting it > to compile. It fails on something as simple as this: > > > #include > > size_t strl