On Mar 24, 2008, at 10:44 PM, Nathan Scott wrote:
On Mon, 2008-03-24 at 20:18 -0700, James Peach wrote:
Hi all,
I just experienced a minor but confusing build issue with awk.
configure found /opt/local/bin/gawk, but it didn't get set in
pcp.conf
with the full path:
blacko:pcp-2.7.4 jpeach$ grep awk config.log
configure:4584: checking for gawk
configure:4600: found /opt/local/bin/gawk
configure:4611: result: gawk
ac_cv_prog_AWK=gawk
AWK='gawk'
awk='gawk'
Now, somewhere later in the build PCP_AWK_PROG is run but $PATH is
reset. This means that awk isn't found and mysterious build failures
ensue.
IMO, AC_PROG_AWK should give the absolute path, but something like
this should take care of the problem:
--- pcp-2.7.4/configure.in 2007-09-07 04:37:11.000000000 -0700
+++ pcp-2.7.4.jpeach/configure.in 2008-03-24 20:14:14.000000000 -0700
@@ -409,6 +409,10 @@
dnl installed on linux.
test "$AWK" = "mawk" -a -x /usr/bin/awk && AWK=awk
awk=$AWK
+case $awk in
+ /*) ;;
+ *) awk=`which $awk` ;;
+esac
AC_SUBST(awk)
test -z "$SED" && AC_PATH_PROG(SED, sed, /bin/sed)
One issue with that approach is that it only handles AWK,
whereas there are a number of programs configure is trying
to find. It also doesn't use the existing mechanism in
PCP for handling this, which is the /etc/pcp.env path list
I mentioned earlier. We should pick one or the other, the
less invasive approach being the addition of the Mac local
binary directory to the existing list of paths.
OK, I see what you mean. This doesn't fit into the configure model
very well. If configure is going to find random binaries in your
$PATH, then it needs to make sure that pcp.env has the same $PATH that
was used at configure time. However it's probably not appropriate for
system services to use the $PATH of some random joe who happened to
run configure.
My vote is to default to using the absolute path to well-known
utilities and allow configure-time overrides. (I think this is what
Nathan's sed example does?)
|