+use_configure yes
This is a default value so you could leave the line out.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
On Thu, August 4, 2011 9:59 am, David Baumgold wrote:
The python27 portgroup sets use_configure no, so I had to override it back
to yes.
Ah, missed that! Good call :-)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
On Thu, August 4, 2011 9:59 am, David Baumgold wrote:
The python27 portgroup sets use_configure no, so I had to override it back
to yes.
You really didn't have to. use_configure yes means use the default configure
phase. use_configure no means don't use the default configure phase.
Doesn't
On 2011-08-03 05:16 , Ryan Schmidt wrote:
On Aug 2, 2011, at 13:11, Rainer Müller wrote:
I feel like we should finally decide on a policy to give
maintainers affirmation when it's okay to use those new features.
I feel two weeks would probably be a good rule now, because that's
the trigger
Several KDE ports utilize meinproc4 in their build process [1]. It seems,
at least with the system I'm on, that they will segfault if they aren't
run as root, either through MacPorts or manually.
Is this the case of it trying to access dot files in a home directory it
doesn't own? There was
Hi there,
I’ve raised the llvm-devel port from the dead to support a new “dragonegg”
port. I could have selected to use 2.9 version of both, but it seems some
important fixes have been committed since, so the choice of the svn version
makes more sense. To those who are not familiar with
On Thu, Aug 04, 2011 at 08:51:15PM +0200, vincent habchi wrote:
Hi there,
I’ve raised the llvm-devel port from the dead to support a new “dragonegg”
port. I could have selected to use 2.9 version of both, but it seems some
important fixes have been committed since, so the choice of the svn
Jack,
Note that if you are using upstream llvm and dragonnegg svn, the current code
now supports building dragonegg against both gcc 4.5.3 and gcc 4.6.1.
Yes! The dragonegg port has both gcc45 and 46 variants, and produces output
files named dragonegg45.so and dragonegg46.so, so that you can
On Aug 4, 2011, at 14:21, s...@macports.org wrote:
Revision: 81769
http://trac.macports.org/changeset/81769
Author: s...@macports.org
Date: 2011-08-04 12:21:20 -0700 (Thu, 04 Aug 2011)
Log Message:
---
digikam: update to 2.0.0, #30576
Modified Paths:
On Aug 4, 2011, at 14:18, ma...@macports.org wrote:
Revision: 81768
http://trac.macports.org/changeset/81768
Author: ma...@macports.org
Date: 2011-08-04 12:18:06 -0700 (Thu, 04 Aug 2011)
Log Message:
---
Update to 1.4.5. Closes #30133.
Modified Paths:
On Aug 4, 2011, at 21:41, mm...@macports.org wrote:
Revision: 81802
http://trac.macports.org/changeset/81802
Author: mm...@macports.org
Date: 2011-08-04 19:41:43 -0700 (Thu, 04 Aug 2011)
Log Message:
---
graphics/ogre: new port, see #26239
+destroot {
+copy
FYI, clang ignores CPATH and LIBRARY_PATH.
http://llvm.org/bugs/show_bug.cgi?id=8971
So that's fun, and could cause issues with some ports that have come to rely on
MacPorts setting CPATH and LIBRARY_PATH, such as:
https://trac.macports.org/ticket/30271
https://trac.macports.org/ticket/28220
12 matches
Mail list logo
