On Apr 15, 2007, at 10:35, James Berry wrote:
- Add -I${prefix}/include -L${prefix}/lib to the default configure
flags (pguyot in r23246 and r23291).
Ok, so after r23291, we're adding these in cppflags and ldflags, and -
O2 in cflags and cxxflags.
But I thought we said in a previous discussion that using CPATH and
LIBRARY_PATH was a better solution? Was there a conscious decision
not do do it that way, and if so why?
- New options for configure flags (C|CPP|CXX|LD)FLAGS and logic to
handle that and backward compatibility (pguyot in r23089,
r23125,
r23238, r23248 and r23249).
r23089 isn't by pguyot and isn't related to this change.
r23238 is the one that deletes the "command" command, and adds the
"command_exec" command. So this means that the ports that still use
the "command" command are now broken:
$ grep '\[command' */*/Portfile
aqua/radassist/Portfile: system "[command patch] < \"$
{workpath}/patch-darwinports\""
devel/curlhandle/Portfile: system "[command build]"
devel/libsdl-framework/Portfile: system "[command build]"
net/nefu/Portfile: system "[command build]"
textproc/gpsbabel/Portfile: system "[command build]"
Boey Maun Suang said he could work on a patch for radassist in the
thread "How can I determine if a function is available?" but I'm
wondering if it might not be easier and better to just delete the
port. If anyone cares about radassist they should speak up now.
For gpsbabel I'm CCing the maintainer. For the others, they have no
maintainer.
- "port sync" now updates svn repos too (eridius in r22784).
Ooh, thanks! And I was just about to share a bash function to do
this. Now I don't have to. :)
- Default +universal variant for configure-based ports (pguyot in
r22313).
Ooh, it did make it into 1.4.1! Great! Thanks!
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
