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
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
