MacPorts 1.4.1 has been released for selfupdate. It should hit the rsync servers within an hour or so. If you already have macports installed, simply "sudo port selfupdate". If you're doing a new install, install from the 1.4.0 disk image, then do a selfupdate. MacPorts 1.4.1 is a minor bugfix/feature release. ChangeLog entries include: Release 1.4.1 (14-Apr-2007): - Add responsive, reasonably fast http mirrors to openbsd group (pipping in r23343). - Resolved ticket #11637: livecheck incorrectly assumed that master_sites was set. (pguyot in r23329). - Add xar 1.4 into the build of MacPorts base. xar is now installed into /opt/local/, which will conflict with anybody who has the xar port installed. (jberry in r23687). - Add -I${prefix}/include -L${prefix}/lib to the default configure flags (pguyot in r23246 and r23291). - 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). - "port sync" now updates svn repos too (eridius in r22784). - Default +universal variant for configure-based ports (pguyot in r22313). - Fixed use of master_site in livecheck, added support for code.google.com checks, made the up to date message info (instead of debug) and improved debugging output with livecheck (eridius in r23888, r23889, r23890, r23894; pguyot in 23660) - Fixed a bug where running port test would not install dependencies when required. (pguyot in r23700) - New ruby portgroup option to specify the name of the module for gem-based ports. (pguyot in 23659) - New fetch option to ignore the SSL certificate when fetching from a secure site (default is to not ignore it). (pguyot in r23242) - Bugfix #11720. Fixes for variants.conf functionality. (jberry in r23967)
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!
On Apr 16, 2007, at 10:20 AM, Ryan Schmidt wrote:
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?
The rationale was that most ports currently alter *FLAGS and not *PATH and the goal was to break as few ports as possible with the update. In fact, I believe the only ports that were broken are ports that use command private API. Moreover CPATH and LIBRARY_PATH definitely do not have the same semantics as *FLAGS. These includes come *after* the -I parameters on the command line, and therefore ports might more likely pick the system include/libraries where *FLAGS, for autoconf-based ports, are usually *before* the other -I parameters.
- 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.
This is a typo. The change is 23098 For the record, the dependency between changes are the following: - new command exec API -> flags -> universal i.e., to work +universal requires the new flags code which requires the new command exec API.
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]"
Exactly. But I have strictly no pity about those. We can't work on base/ if there isn't a clear limit between what can be in ports and what should not be there. Now, a short-term fix is to replace system "[command build]" with command_exec build. The patch line is more complex to fix simply because command doesn't do what these port writers thought it did. command invokes a particular command with command.* options, such as command.args, etc. system "[command patch] < \"${workpath}/patch-darwinports\"" should never have appeared in the first place, it worked by chance. Any change of the patch code would have broken that. And this behavior: post-patch { file copy ${filespath}/patch-darwinports.in ${workpath}/patch- darwinports reinplace "s|@PREFIX@|${prefix}|g" ${workpath}/patch-darwinports system "[command patch] < \"${workpath}/patch-darwinports\"" } should be replaced with patching first and replacing after, like all other ports do: patchfiles patch-darwinports post-patch { reinplace "s|@PREFIX@|${prefix}|g" ... reinplace "s|@PREFIX@|${prefix}|g" ... reinplace "s|@PREFIX@|${prefix}|g" ... reinplace "s|@PREFIX@|${prefix}|g" ... } There are other solutions that are less ugly than what currently is in this port. Paul
In article <EF666B3B-1B9F-4C67-890A-92259A131643@macports.org>, James Berry <jberry@macports.org> wrote:
MacPorts 1.4.1 has been released for selfupdate. It should hit the rsync servers within an hour or so.
If you already have macports installed, simply "sudo port selfupdate". If you're doing a new install, install from the 1.4.0 disk image, then do a selfupdate.
Doesn't work on 10.3.9. "sudo port -v selfupdate" ends with: checking for xml2-config... /usr/bin/xml2-config checking for libxml >= 2.6.11... 2.6.16 checking libxml/xmlwriter.h usability... no checking libxml/xmlwriter.h presence... no checking for libxml/xmlwriter.h... no configure: error: Cannot build without libxml2 configure: error: ./configure failed for src/programs/xar It's picking up the xml2-config from the BSD package which points it at /usr/include/libxml2/libxml - the contents of which come from the DevSDK package and don't include xmlwriter.h If I temporarily rename xml2-config out of the way it doesn't find the one from dports, it just says it can't find xml2-config at all. Do I still have a functioning 1.4.0 install or am I hosed? Dave -- Dave Hill - dave at hillcroft dot org dot uk
participants (4)
-
Dave Hill
-
James Berry
-
Paul Guyot
-
Ryan Schmidt