pcp
[Top] [All Lists]

Re: build issue with AC_PROG_AWK

To: nscott@xxxxxxxxxx
Subject: Re: build issue with AC_PROG_AWK
From: James Peach <jamespeach@xxxxxxx>
Date: Wed, 26 Mar 2008 13:50:52 -0700
Cc: pcp@xxxxxxxxxxx
In-reply-to: <47545.192.168.3.1.1206563853.squirrel@xxxxxxxxxxxxxxx>
References: <FC71FBC1-38F6-4CA8-A82C-7FFE102A06BF@xxxxxxx> <1206423840.29868.340.camel@xxxxxxxxxxxxxxxxx> <18408.37725.85447.784561@xxxxxxxxxxxxxxxxxxxxxx> <47E894C7.2000903@xxxxxxx> <1206426896.29868.344.camel@xxxxxxxxxxxxxxxxx> <7138BC3A-DEC1-432A-B77C-59BC65E53BE7@xxxxxxx> <1206506319.29868.395.camel@xxxxxxxxxxxxxxxxx> <B4107BB9-D5FC-46C5-AF41-FAEA685E254F@xxxxxxx> <47545.192.168.3.1.1206563853.squirrel@xxxxxxxxxxxxxxx>
Sender: pcp-bounce@xxxxxxxxxxx
On Mar 26, 2008, at 1:37 PM, nscott@xxxxxxxxxx wrote:
On Tue, 2008-03-25 at 19:48 -0700, James Peach wrote:
-       /usr/contrib/bin /opt/local/bin
+       /usr/contrib/bin

You really don't like this bit do you? :) ... I think
since we have /usr/local/bin for Linux, we should also
do this for consistent behaviour on Mac.


Yes, I *really* hate it :)

First, OS X has 2 possible sources of additional software - MacPorts
and Fink. MacPorts installs in /opt/local and Fink (IIRC) installs in /
fw.

OK, thats not an argument for removing it though.

True enough. I'm just trying to illustrate that continuing to add to the list of places where things could start getting out of hand.

Second, as a matter of policy I don't think that PCP should be using
random tools from all over the system.

Its not random, its very specific, and its meant to cover the places that
configure is going to go look for binaries (I think).

configure is going to look in $PATH. Whatever the path in pcp.env is, it's not what $PATH was when I ran configure. configure might just as easily find the gawk in ~/bin/gawk.

Personally, I don't like this & tend to agree with you, but the reality is
thats how all of the ports have been done.  And I don't think there's
much reason to deviate from that for one particular port - the only
real options are to either fix it for all (i.e. remove all the "special" case
PATH additions) - a QA nightmare - or tow the line.

I guess that I'm advocating (but not volunteering to QA) the second option :)



Third I think that the whole concept of searching the $PATH of the
person who ran configure is wrong. If PC is going to search the

That's not what pcp.env is doing (though its not clear what you meant by
"PC" above).

I meant PCP.



builder's $PATH, then it should update the PATH in pcp.env. Otherwise
it should only search the path in pcp.env, since that is what will be
searched at the time when these tools are actually needed.

cheers.

--
Nathan



<Prev in Thread] Current Thread [Next in Thread>