Re: [141201] trunk/dports/math/ceres-solver/Portfile

> On Oct 12, 2015, at 5:54 PM, Joshua Root <j...@macports.org> wrote: > > On 2015-10-13 08:26 , Mark Moll wrote: >> >>> On Oct 12, 2015, at 4:11 PM, Ryan Schmidt <ryandes...@macports.org> wrote: >>> >>> >>>> On Oct 12

Re: [141201] trunk/dports/math/ceres-solver/Portfile

> On Oct 12, 2015, at 4:11 PM, Ryan Schmidt wrote: > > >> On Oct 12, 2015, at 12:25 PM, mm...@macports.org wrote: >> >> Revision >> 141201 >> Author >> mm...@macports.org >> Date >> 2015-10-12 10:25:29 -0700 (Mon, 12 Oct 2015) >> Log Message >> >> ceres-solver:

erlang expert needed for rabbitmq-server port

The rabbitmq-server is broken in various ways (see https://trac.macports.org/ticket/47799). By default files are installed in non-standard places, which the port is (unsuccessfully) trying to fix. On top of the old version of the port doesn’t even compile with the current version of erlang. By

Re: python: finding specific library version via CMake

On Jun 29, 2015, at 9:18 PM, Mark Moll mm...@rice.edu wrote: On Jun 29, 2015, at 8:10 PM, Ryan Schmidt ryandes...@macports.org wrote: On Jun 24, 2015, at 3:04 PM, Mark Moll wrote: Part of the problem is that there is no way to force the default CMake modules for finding an python

Re: python: finding specific library version via CMake

On Jun 29, 2015, at 8:10 PM, Ryan Schmidt ryandes...@macports.org wrote: On Jun 24, 2015, at 3:04 PM, Mark Moll wrote: Part of the problem is that there is no way to force the default CMake modules for finding an python interpreter and python libraries to agree on the same version

Re: python: finding specific library version via CMake

Part of the problem is that there is no way to force the default CMake modules for finding an python interpreter and python libraries to agree on the same version. As a way around that I wrote my own FindPython.cmake: https://bitbucket.org/ompl/ompl/src/tip/CMakeModules/FindPython.cmake You

Re: Adding MPI back to Boost

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

odd problem with blacklisting compilers

/steps/compile/logs/stdio What’s going on? -- 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: py-shiboken cmake

something like this: cmake -DCMAKE_PREFIX_PATH=${prefix}//Library/Frameworks/Python.framework/Versions/2.7 This might be more robust, though. Unless someone objects, I’ll make the suggested changed to py-shiboken. -- Mark Moll signature.asc Description: Message signed with OpenPGP

different versions of port for different versions of OS X

/macports/distfiles/py-graph-tool --- Attempting to fetch graph-tool-2.2.31.tar.bz2 from http://distfiles.macports.org/py-graph-tool (Full log at https://build.macports.org/builders/buildports-lion-x86_64/builds/19772/steps/compile/logs/stdio) Any ideas what’s going on? -- Mark Moll

Re: New MacPorts web site

@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev -- Mark Moll signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org

Re: Move part of macports infrastructure to GitHub

to mercurial, but for git I am often still stuck using the SourceTree GUI from the Bitbucket folks to figure out what I am doing. I am sure I could get used to git, though. -- Mark Moll signature.asc Description: Message signed with OpenPGP using GPGMail

Re: [116766] trunk/dports/science/ompl/Portfile

a number of variants for gccxml-devel, one for each compiler that it can simulate? gccxml-devel can be *compiled* with many compilers, but can only *simulate* a subset of those compilers. By default it simulates the compiler that was used to compile it. -- Mark Moll

Re: [113214] trunk/dports/python/py-graph-tool/Portfile

builds fine on my Mavericks machine with the latest Xcode. Is this a C++98 vs C++11 error or a OS X 10.[678] vs 10.9 error? What is the proper way to fix this? -- Mark Moll ___ macports-dev mailing list macports-dev@lists.macosforge.org https

Re: [113226] trunk/dports/python/py-graph-tool/Portfile

, for example, would cause problems. I can’t think of a good solution for this. For now, the port might be Mavericks only. -- Mark Moll ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo

Re: [110825] trunk/dports/python/py-graph-tool/Portfile

]} Thanks, fixed in r110854. -- 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

compiler.blacklist ignored on snow leopard

at the build log for the Snow Leopard build slave you’ll see that it is still using /usr/bin/llvm-g++-4.2: https://build.macports.org/builders/buildports-snowleopard-x86_64/builds/19334 Do I explicitly need to specify a compiler for Snow Leopard? -- Mark Moll signature.asc Description

Re: [105866] trunk/dports/python/py-graph-tool/Portfile

*. Could be. It uses very heavily-templated code, so I wouldn’t be surprised if it was a problem for gccXX as well. I don’t have an easy way to test it, since I think I’d have to recompile boost with gccXX as well. -- Mark Moll ___ macports-dev

buildbot says py27-graph-tool package exists, packages.macports.org disagrees

The build bot thinks the py27-graph-tool port has already been built: https://build.macports.org/builders/buildports-mtln-x86_64/builds/70/steps/compile/logs/progress But this folder doesn’t exist: http://packages.macports.org/py27-graph-tool How can that be? -- Mark Moll

Re: [88407] trunk/dports/lang/gccxml-devel/Portfile

On Jan 3, 2012, at 1:45 AM, Ryan Schmidt wrote: On Jan 2, 2012, at 20:54, Mark Moll wrote: Does it work now? No. Same error. OS X 10.7.2, MacPorts 2.0.99 at first, now 2.0.3. Do you see the same kind of problem with any of the hundreds of other ports that fetch from a version control

Re: [88407] trunk/dports/lang/gccxml-devel/Portfile

On Jan 1, 2012, at 5:18 PM, Ryan Schmidt wrote: On Jan 1, 2012, at 12:48, Mark Moll wrote: On Dec 30, 2011, at 11:20 PM, Ryan Schmidt wrote: On Dec 30, 2011, at 23:19, mm...@macports.org wrote: Revision: 88407 http://trac.macports.org/changeset/88407 Author: mm

Re: [81802] trunk/dports/graphics

in the “official” binary Ogre SDK release. It includes both pkg-config and cmake files, so if there are any Ogre developers on this list, please give it a try. -- Mark Moll ___ macports-dev mailing list macports-dev@lists.macosforge.org http

Re: [60495] trunk/dports/science/hdf5-18

On Nov 14, 2009, at 7:21 AM, Jochen Küpper wrote: On 14.11.2009, at 01:04, mm...@macports.org wrote: Remove old cruft and threadsafe variant which is unsupported on OS X Well, the variant was unsupported, but where does it say that the HDF5 configure option as such is unsupported on OS

Re: [60495] trunk/dports/science/hdf5-18

On Nov 14, 2009, at 10:38 AM, Mark Moll wrote: On Nov 14, 2009, at 7:21 AM, Jochen Küpper wrote: On 14.11.2009, at 01:04, mm...@macports.org wrote: Remove old cruft and threadsafe variant which is unsupported on OS X Well, the variant was unsupported, but where does it say that the HDF5

Re: HDF5 dilemma

HDF5 1.6.10 and HDF5 1.8.4 are currently in prerelease. HDF5 1.6.10 is the last release of the 1.6.x series. HDF5 1.8.x can also be compiled in 1.6.x compatibility mode, but this shouldn’t be done by default. I think it’s hard to make a case for the hdf5_select approach you suggest. First,

installing Rpy using MacPorts

I am trying to create a port for rpy2, an interface to R from python. I have R and python2.6 installed through MacPorts. When I run python setup.py build in the rpy2-2.0.6 directory, I get the following error: --- Computing dependencies for py26-rpy --- Building py26-rpy Error: Target

Re: [47678] trunk/dports/science/hdf5-18

On Mar 4, 2009, at 2:41 AM, Ryan Schmidt wrote: On Mar 3, 2009, at 11:28, mm...@macports.org wrote: Revision: 47678 http://trac.macports.org/changeset/47678 Author: mm...@macports.org Date: 2009-03-03 09:28:49 -0800 (Tue, 03 Mar 2009) Log Message: --- build hdf5-18

Re: linking c/c++ code against fortran libraries

On May 31, 2008, at 8:21 AM, Takeshi Enomoto wrote: Hi, However, to properly link against libfoo.a I also need to include -lgfortran. With a fortran compiler, necessary libraries will be linked. Yes, but I can't specify in a Portfile two compilers (one for compiling c/c++ code, and one

linking c/c++ code against fortran libraries

There are number of ports that have variants for choosing one the fortran compilers: gcc42, gcc43, and g95. Suppose now that I have port A that includes a library libfoo.a of fortran code. I would like to create a port B that contains C code and depends on this library in port A. However,

updated portfile for games/xmj

Can someone please commit http://trac.macports.org/projects/macports/ ticket/12078, a version bump for games/xmj? -- Mark ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev

NEW: math/qhull port

Can somebody commit this: http://trac.macports.org/projects/macports/ticket/11990 NEW: qhull 2003.1 New port for the qhull package. Qhull computes the convex hull, Delaunay triangulation, Voronoi diagram, halfspace intersection about a point, furthest-site Delaunay triangulation,

NEW: arpack

Could someone commit this new port?: arpack, a package for solving large scale eigenvalue problems http://trac.macports.org/projects/macports/ticket/11279 -- Mark ___ macports-dev mailing list macports-dev@lists.macosforge.org