Date: Sat, 12 Jan 2019 13:21:30 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 234833] USES=autoreconf fails if a port uses gettext but user disables NLS port option Message-ID: <bug-234833-7788-jan7AX0hJi@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-234833-7788@https.bugs.freebsd.org/bugzilla/> References: <bug-234833-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D234833 --- Comment #10 from Matthias Andree <mandree@FreeBSD.org> --- Tijl, let's not discuss autoconf details, but thanks for remaining construc= tive and explaining your vantage point and focus. I know all those because I think all upstream packages I maintain use it, a= nd I've introduced most of the things. Proposing to reimplement autoreconf in Makefile syntax is certainly something that I know will not happen in FreeB= SD ports, it was provocative just as I perceive the assumption everyone has NLS stuff installed as presumptuous. Let's get back to the original issue I have had, and that is:=20 *disabling* NLS made the port build in poudriere fail in a pretty non-obvio= us way. The port configure phase fails when it cannot find autopoint in poudri= ere, and you as the port contributor start thinking, hang on, I deselect NLS and then it fails because it doesn't have some NLS developer tool? I know from a more distant view and with more thinking one can recognize th= at autopoint is normally a development-time requisite, that - through USES+=3Dautoreconf - has been made a build-time requisite. /!\ -> It seems that either I have not been looking in the right places, or that the Uses/Mk/autoreconf.mk comment banner and/or OptionsNG "NLS" documentation and possibly implementation are incomplete. I see several alternative solutions out portmgr/global scale: a. have autoreconf.mk introduce build requisites on ALL tools potentially invoked by autoreconf from its scanning the Makefile.am/configure.ac and whatnot. From scanning the documentation, that is autoconf, automake, libto= ol, gettext, m4, with all its development siblings. b. have autoreconf.mk scan the configure.* for required tools and add that = set of requisites to BUILD_DEPENDS. c. some middle way between b. and d., not adding, just warning with DEVELOPER=3Dyes d. document what other tools might be required by USES=3Dautoreconf. This = is certainly non-obvious, just the routine "if it fails in poudriere but not in the plain system, some requisite is missing from _DEPENDS" let me figure th= is out. We may also need to hint to a list of GNU tools such as coreutils, GNU grep, GNU sed, and bash, as these are often requisites when the packages have been predominantly developed on Linux, but I would not cast these into foo_DEPEN= DS+=3D or USES+=3Dbar entries. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-234833-7788-jan7AX0hJi>