> On Oct 12, 2015, at 5:54 PM, Joshua Root wrote:
>
> On 2015-10-13 08:26 , Mark Moll wrote:
>>
>>> On Oct 12, 2015, at 4:11 PM, Ryan Schmidt wrote:
>>>
>>>
>>>> On Oct 12, 2015, at 12:25 PM, mm...@macports.org wrote:
>>>&
> 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: update to version 1.11.0
>
>>
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
> On Jun 29, 2015, at 9:18 PM, Mark Moll wrote:
>
>>
>> On Jun 29, 2015, at 8:10 PM, Ryan Schmidt 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
> On Jun 29, 2015, at 8:10 PM, Ryan Schmidt 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
&g
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 can
pi 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
/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
My reason for deleting these files was that the different py*-shiboken ports
write to the same files. I figure that dependent ports would just do something
like:
cmake -DSHIBOKEN_INCLUDE_DIRS=… -DSHIBOKEN_LIBRARIES=…
With your solution you still need to do something like this:
doesn't seem to exist in
/opt/local/var/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
regardless whether you’re on a Mac, iPad, or iPhone. To make the site look
>> less like other Bootstrap sites, we could customize the fonts and colors, by
>> trying out a number of third-party Bootstrap themes such as those at
>> Bootswatch, or by making our
mercurial over git. It’s fairly easy to transition from
svn 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
sign
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
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
enable
C++11 for one port and not its dependencies, as I found out. I suspect I can’t
remove the “-std=c++11” flag and use gcc48 for example, since this would use
libstdc++ and boost would be using libc++. The RTTI used by Boost.Python, for
example, would cause problems. I can’t think of
libtool
>
> You’re also going to need dependencies on autoconf and automake.
I fixed that, but now I get a different error (during compilation):
./../graph_adjacency.hh:26:10: fatal error: 'tuple' file not found
#include
^
1 error generated.
Everything builds fine on my Maver
o
>>depends_build-append port:pkgconfig
>>depends_lib-append port:boost \
>
> If you want to blacklist all GCC 3.3, 4.0, 4.2, and 4.3, you can do this:
>
>compiler.blacklist gcc-3.3 {*gcc-4.[0-3]}
Thanks, fixed in r110854.
--
Mark Moll
signature.asc
Descript
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
leave parallel building on when configure.compiler does not
> match "*clang*".
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 mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
t.
>
> For example from the conflicts_build portgroup:
>
>
>if {${subport} == ${badport}} {
> ui_error "${subport} cannot be built while another version of
> ${badport} is active."
>ui_error "Please deactivate the existing copy of ${badport}
> and try again."
>} else {
>ui_error "${subport} cannot be built while ${badport} is
> active."
>ui_error "Please deactivate ${badport} and try again."
>ui_error "You can reactivate ${badport} again later."
>}
>return -code error "${badport} is active"
Thanks for that suggestion. Done.
--
Mark Moll
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
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
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
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
>
.activate org.macports.checksum org.macports.extract
org.macports.patch org.macports.configure org.macports.build
org.macports.destroot org.macports.install
Log for gccxml-devel is at:
/opt/local/var/macports/logs/_Users_mmoll_src_macports_dports_lang_gccxml-devel/gccxml-devel/main.log
--
Mark Moll
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
+}
>> +configure.universal_args-delete --disable-dependency-tracking
>
>
> I'm guessing this was necessary because you wanted both cmake and xcode, and
> the two portgroups didn't play nice together? I wonder if there's any way we
> could fix th
akefile fix it?:
include ${PETSC_DIR}/conf/variables
include ${PETSC_DIR}/conf/rules
What is the exact error message you get?
--
Mark Moll
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
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
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
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,
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 o
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 wit
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
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, t
Hi,
Can someone commit the following ports I have submitted quite a while
back:
http://trac.macports.org/ticket/15175
Added support to arpack port for using different fortran compilers
(the same way it is done for e.g. py25-scipy).
http://trac.macports.org/ticket/14832
New port for PETSc, a
I've update avr-gdb to the latest version of gdb. This seems to fix a
build problem on Leopard. Can someone please commit:
http://trac.macports.org/projects/macports/ticket/13215
(I'm the maintainer, but don't have commit rights.)
--
Mark
___
macpor
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
On May 30, 2007, at 7:44 AM, Jochen Küpper wrote:
On 30.05.2007, at 05:06, [EMAIL PROTECTED] wrote:
updated to py-numpy version 1.0.3 swapped dependency from gcc41/
gcc42 to g95, much to the joy of everyone
Not for me!
I very much prefer gfortran over g95 for various reasons --
performance
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, an
Can someone please commit this port update?:
http://trac.macports.org/projects/macports/ticket/11889
--
Mark
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
uel Palacios wrote:
On Feb 14, 2007, at 2:16 PM, Mark Moll wrote:
Could someone commit this new port?:
arpack, a package for solving large scale eigenvalue problems
http://trac.macports.org/projects/macports/ticket/11279
--
Mark
Committed with minor revisions in r22025, thanks for the
c
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
http://lists.macosforge
Sorry, I have diff aliased to colordiff. Corrected patch attached.
Thanks for creating a ticket.
Begin forwarded message:
From: Cédric Luthi <[EMAIL PROTECTED]>
Date: December 18, 2006 2:12:59 PM PST
To: macports-dev@lists.macosforge.org
Cc: Mark Moll <[EMAIL PROTECTED]>
Subject
[I can't create tickets since the wordpress/trac merge, so maybe
someone else can create a ticket.]
New port: arpack.
ARPACK is a collection of Fortran77 subroutines designed to solve
large scale eigenvalue problems. homepage http://www.caam.rice.edu/
software/ARPACK/
The solvers for comp
[I can't create tickets since the wordpress/trac merge, so maybe
someone else can create a ticket.]
This is a version bump for OpenMPI. I have added a fortran variant,
which is needed for the ARPACK port with the mpi variant (see my next
message).
--
Mark
openmpi.patch
Description: Binar
On Dec 11, 2006, at 1:44 AM, Ian Eiloart wrote:
--On 10 December 2006 20:15:04 -0800 Mark Duling
<[EMAIL PROTECTED]> wrote:
Mark Moll <[EMAIL PROTECTED]> on Sunday, December 10, 2006 at 7:12 PM
-0800
wrote:
I'm having the same difficulties with creating new ticket
44 matches
Mail list logo
