December 2007 - macports-dev - lists.macosforge.org

Fwd: freeciv patch when bind9 is installed
by Randall Wood 02 Dec '07

02 Dec '07

---------- Forwarded message ---------- From: Bryan Blackburn <blb(a)macports.org> Date: Dec 1, 2007 6:12 PM Subject: freeciv patch when bind9 is installed To: Randall Wood <rhwood(a)macports.org> FYI, when bind9 is installed (including the ${prefix}/lib/libbind.a archive), freeciv has issues building since it's looking in both a dylib (libSystem) and the archive for gethostbyaddr when running configure. Attached is a patch to configure to skip trying -lbind to get it to build nicely on the Mac. Not sure if you will want this in the general patchfiles list or a darwin-specific one. Thanks, Bryan -- Randall Wood randall.h.wood(a)alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."

1 0

Re: [31639] trunk/dports/sysutils/duplicity/Portfile
by Ryan Schmidt 02 Dec '07

02 Dec '07

On Nov 30, 2007, at 20:43, ram(a)macports.org wrote: > Revision: 31639 > http://trac.macosforge.org/projects/macports/changeset/31639 > Author: ram(a)macports.org > Date: 2007-11-30 18:43:49 -0800 (Fri, 30 Nov 2007) > > Log Message: > ----------- > sysutils/duplicity: disable universal variant That's clear from the diff. The log message should really go a bit further to explain why the change is being made. Is it because the software is non-binary and therefore architecture-agnostic? or is it because the universal build process is currently broken for this software and a solution is not yet known? or because it only builds universal when hosted on one architecture but not the other? Putting this in the log will help people looking at the port later decide whether they should invest time in trying to make the port work universal or not.

1 0

Re: [31655] trunk/dports/lang/sbcl
by Ryan Schmidt 02 Dec '07

02 Dec '07

On Dec 1, 2007, at 16:31, waqar(a)macports.org wrote: > Revision: 31655 > http://trac.macosforge.org/projects/macports/changeset/31655 > Author: waqar(a)macports.org > Date: 2007-12-01 14:31:16 -0800 (Sat, 01 Dec 2007) > > Log Message: > ----------- > Updated to the latest release of the software and fixed the build > on Leopard. > > Modified Paths: > -------------- > trunk/dports/lang/sbcl/Portfile > > Added Paths: > ----------- > trunk/dports/lang/sbcl/files/base-target-features.patch Patchfiles should be named "patch-whatever.diff". "port lint" in MacPorts 1.6.0 will flag this as a warning otherwise. Especially for new patchfiles, there's no reason not to follow the recommended patchname convention.

1 0

New port needs commit -- asymptote
by Luis O'Shea 01 Dec '07

01 Dec '07

I have created a port for asymptote, see ticket 13249. Could someone please review and commit it? Thanks. This is my first port, so it's probably worth checking that I haven't done anything too silly. Luis O'Shea

1 0

+x11, and +quartz variants (or a dangerous idea)
by Randall Wood 01 Dec '07

01 Dec '07

I would like to suggest that the variants +quartz and +x11 should be supported where relevant, eliminating the use of the +no_x11 variant: +quartz Enable building the port to render graphics using the quartz engine and aqua user interface +x11 Enable building the port to use X11 Furthermore, I would like to suggest that these variants should never be default variants and that we should modify the macports base to recognize that a port has these variants and if neither is selected (either at the command line or in variants.conf) that an error message should be displayed explaining that the port may be installed with either: +quartz, +x11, or +quartz+x11, although some ports may result in unpredicatable behavior if +quartz+x11 is used. Furthermore, I would like to suggest that the +no_x11 variant and the +no_quartz (if it is used at all) variants should be actively discouraged. Background: I have removed X11 from my laptop and am building (albeit slowly) and using applications that I used to run under X11 under Aqua or am using an Aqua-based (roughly) equivilent application. This has revealed a number of instances of ports assuming that X11 is installed on a Mac OS X box, when that assumition is or should be false, such as when the upstream project is supporting Quartz-only builds, or when the project actually only really cares if GTK+ is installed, but the port hauls in X-based dependencies anyway. Some ports even build both the X11 and Quartz libraries for the port, but then only advertize to subsequent and dependent builds only the Quartz library. While working through this, I realized that we should assume that X11 is not available on a machine and that we should re-gin our ports to match that assumption. Right now the assumption for most ports is that X11 is installed on a machine, and that users would prefer items that provide both X11 and Quartz should always provide X11 versions and should only maybe provide Quartz versions. Randall Wood randall.h.wood(a)alexandriasoftware.com http://shyramblings.blogspot.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."

5 5