[Bug 234833] USES=autoreconf fails if a port uses gettext but user disables NLS port option

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234833

--- Comment #10 from Matthias Andree <mandree at FreeBSD.org> ---
Tijl, let's not discuss autoconf details, but thanks for remaining constructive
and explaining your vantage point and focus.

I know all those because I think all upstream packages I maintain use it, and
I've introduced most of the things. Proposing to reimplement autoreconf in
Makefile syntax is certainly something that I know will not happen in FreeBSD
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: 
*disabling* NLS made the port build in poudriere fail in a pretty non-obvious
way. The port configure phase fails when it cannot find autopoint in poudriere,
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 that
autopoint is normally a development-time requisite, that - through
USES+=autoreconf - 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, libtool,
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=yes

d. document what other tools might be required by USES=autoreconf.  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 this
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_DEPENDS+=
or USES+=bar entries.

-- 
You are receiving this mail because:
You are on the CC list for the bug.