MacPorts 1.4.1 released for self update

[Paul Guyot]

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