Bug 38090
| Summary: | devel/m4 port PREFIX vs LOCALBASE | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Danny Howard <djh> |
| Component: | Individual Port(s) | Assignee: | Ade Lovett <ade> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | CC: | ade |
| Priority: | Normal | ||
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
Responsible Changed From-To: freebsd-ports->jkoshy I will look at this PR. Responsible Changed
From-To: jkoshy->ade
This appears to be a buglet in the autoconf 'port': we appear
to be explicitly adding 'M4=$LOCALBASE/bin/gm4' to CONFIGURE_ENV.
However, 'gm4' need not have been found under $LOCALBASE earlier
(it could have been anywhere in $PATH).
A suggested patch is enclosed. We could probably get by removing
this addition to CONFIGURE_ENV entirely -- I'll leave the decision
to 'autoconf's maintainer.
Index: Makefile
===================================================================
RCS file: /cvs/FreeBSD/ports/devel/autoconf257/Makefile,v
retrieving revision 1.51
diff -u -r1.51 Makefile
--- Makefile 29 Jun 2003 01:45:09 -0000 1.51
+++ Makefile 7 Oct 2003 11:25:01 -0000
@@ -30,7 +30,7 @@
GNU_CONFIGURE= yes
CONFIGURE_ENV+= CONFIG_SHELL=${SH}
-CONFIGURE_ENV+= M4=${LOCALBASE}/bin/gm4
+CONFIGURE_ENV+= M4=$(which gm4)
CONFIGURE_ARGS= --program-suffix=${BUILD_VERSION} --without-lispdir
CONFIGURE_TARGET= --build=${MACHINE_ARCH}-portbld-freebsd${OSREL}
On Tuesday, Oct 7, 2003, at 20:40 US/Pacific, Joseph Koshy wrote:
> -CONFIGURE_ENV+= M4=${LOCALBASE}/bin/gm4
> +CONFIGURE_ENV+= M4=$(which gm4)
Hrm. Not too keen on this idea, since bad things happen if 'which gm4'
doesn't return a path, though this is also true of the hardcoded
solution.
Something along the lines
GM4?= ${LOCALBASE}/bin/gm4
CONFIGURE_ENV+= M4=${GM4}
[...]
post-extract:
.if !exists(${GM4})
@${ECHO_CMD} "Unable to locate GNU M4"
@${FALSE}
.endif
Would allow for maximum flexibility for those who put gm4 in odd places.
However, I'm still not really convinced, given the number of other
ports that assume that things are installed in ${LOCALBASE} or
${X11BASE}. In my opinion, if a user is prepared to make those
changes, then there could well be breakage elsewhere, particularly in
the case where things are installed outside of a ${LOCALBASE} or
${X11BASE} scenario.
I guess it could be wrapped into a USE_GM4 variable, once the massive
amount of GNU tool hacking in bsd.port.mk is shifted out to
bsd.gnutools.mk.
Thoughts?
State Changed From-To: open->feedback Not a great deal has happened here. Putting the PR into feedback state so the submitter gets a little poke on the audit trail. If nothing is forthcoming in a couple of weeks, I'll close the PR. State Changed From-To: feedback->closed Submitter email address bounces: <djh@transmeta.com>: host nmx.transmeta.com[63.209.4.215] said: 554 <djh@transmeta.com>: Recipient address rejected: Access denied PR closed for now. |
Autoconf port breaks in devel/m4 is built with PREFIX different from system prefix. (Say, a test build outside of /usr/local, or in my case, using Encap. :) Fix: CONFIGURE_ENV= M4=${LOCALBASE}/bin/gm4 How-To-Repeat: Build m4 port with alternate PREFIX, symlink to install from /usr/local, watch autoconf port build break.