As of ports SVN revision 489889: On a port that sets USES+=autoreconf (such as mail/fetchmail as of 6.3.26_9), if the user disables the NLS port option (through poudriere options -c -n mail/fetchmail, for instance), the configure phase fails when running autoreconf. The latter is looking for autopoint, which then fails: Can't exec "autopoint": No such file or directory at /usr/local/share/autoconf-2.69/Autom4te/FileUtils.pm line 345. I oversee too little of the Mk/Uses/autoreconf.mk rig and its integration with gettext, but putting AUTOPOINT=${TRUE} into autoreconf's environment appears to help, as of autoconf 2.69. AUTOPOINT=: will _not_ work, BTDT. (fetchmail uses a workaround, see <https://bz-attachments.freebsd.org/attachment.cgi?id=201001>)
(In reply to Matthias Andree from comment #0) You can do this: USES= autoreconf gettext-tools NLS_USES=gettext-runtime
Was about to suggest doing the same as comment #1.
(In reply to Tijl Coosemans from comment #1) Tijl, Antoine, thanks for your proposal, but it doesn't hold water. What you propose creates a build-time depends on gettext, which is unnecessary; OTOH USES=autoreconf will go looking for autopoint without depending on it. My point is that either the framework will need to make sure that either: - it establishes that the unpacked distfile requires gettext, and creates proper _DEPENDS entries, - or that it establishes that gettext is not required, and then Mk/Uses/autoreconf.mk needs to set AUTOPOINT=${TRUE} in autoreconf's environment. We should check if the other tools that autoreconf might depend on are treated in the same vain. With "the port uses gettext", I mean AM*GETTEXT() lines in configure.ac, not a formal USES=gettext-whatever declaration. My current workaround that avoids pulling gettext in at run-time, and that works for mail/fetchmail, is: USES= autoreconf:build [...] # <- part of workaround OPTIONS_DEFINE= X11 NLS NTLM POP2 DOCS # <- note NLS listed NLS_USES= gettext NLS_CONFIGURE_ENABLE= nls # This is a workaround for a ports framework bug: # As of r489889 on 2019-01-10, # USES=autoreconf does not seem to get along with disabling the NLS option, # because this would not install gettext-tools, omitting autopoint, # however the configure.ac requests GETTEXT, so autoreconf will barf. # Pulling in gettext-tools unconditionally (even with NLS off) would # be excess and confuse users, so is not an option. # Thus we set USES=autoreconf:build and run autoreconf by ourselves, # overriding AUTOPOINT=true. # pre-configure-NLS-on: (cd ${WRKSRC} && ${LOCALBASE}/bin/autoreconf -f -i) # pre-configure-NLS-off: (cd ${WRKSRC} && ${SETENV} AUTOPOINT=${TRUE} ${LOCALBASE}/bin/autoreconf -f -i)
Well, you can use the one line fix we have been using for a while, which is a **build-time** only dependency on gettext-tools. which means 3 packages, gettext-tools, gettext-runtime and indexinfo, total about 11MB. Which you will most probably already have installed because there are many ports that require NLS anyway. And they will not add any run-time dependencies when you install the packages in the end. Or you can use the convoluted way you describes. But I really do not see the point of having something so complicated for so small thing.
(In reply to Mathieu Arnold from comment #4) Mathieu, sorry for misaddressing you as Antoine. When I read "... [gettext] Which you will most probably already have installed because there are many ports that require NLS anyway", I find that presumptuous. There are valid reasons to globally disable NLS through /etc/make.conf, for instance, on embedded systems. I also agree that the workaround in mail/fetchmail seems overengineered - and that's the actual reason why I have written this PR. My request is to extend the framework so that ports need to work around it and re-implement parts of it. However this is implemented, several ways are possible. Mk/Uses/autoreconf.mk does not currently provide for a way to easily add command-line options, and offers no way to add to its environment. One pretty generic option might be to add AUTORECONF_ENV and AUTORECONF_ARGS variables that autoreconf.mk uses, and that have similar semantics to CONFIGURE_ENV/_ARGS and MAKE_ENV/_ARGS. A more specific one is to just disable autopoint with AUTOPOINT=${TRUE} in its environment, also in autoreconf.mk, if NLS is disabled, just like fetchmail is currently playing it. There are surely other ways, but any proposal will need to make sure that * it is self-contained * does not break the port's build under non-malicious option combinations * does not pull in unneeded requisites * does declare indispensable/compulsory requisites. It's not as though I hadn't read through autoreconf.mk before writing this PR, but I wasn't expecting so much opposition.
...so that ports need _NOT_ work around it [the framework] and reimplement...
autopoint updates all the gettext related build scripts in the work directory so autoreconf can generate a configure script that works with the version of gettext installed on the system. Some bugs are also fixed by this, like old config.rpath treating FreeBSD 10+ as FreeBSD 1. That configure is called with --disable-nls is not known by autoreconf so it always runs autopoint. That makes autopoint a genuine build dependency and USES=gettext-tools has been created for exactly this case (see bug 194038, comment 0). This solution is clean, simple, no hacks required, has no impact on runtime dependencies of the package, and is least likely to break when autotools or gettext are updated to a new version. The various autotools form a complicated tangle that few people actually understand including upstream developers. So there are projects where --disable-nls doesn't work configure looks for gettext anyway and projects with build scripts mixed from different versions of gettext or other autotools. It's just far easier to run plain autoreconf that runs all the tools than to try to come up with hacks that work in all edge cases. Sure, some ports may not strictly need a particular autotool, but most port maintainers get this wrong. I don't know for sure of course but I suspect you don't really know what all the consequences of AUTOPOINT=true are. It *looks* like it works to you but you don't actually know. And you don't know if it will keep working in the next version. That's why I deliberately designed USES=autoreconf to be as simple as possible (i.e. no things like AUTORECONF_ENV and AUTORECONF_ARGS) so port maintainers would not be tempted to use hacks. In the end it makes their life easier and mine as well when I have to update one of the autotools. So please, just add USES=gettext-tools.
I happen to be the upstream maintainer of fetchmail (whilst *not* maintaining FreeBSD's port) and believe that I know what I am doing with all GNU autotools (except libtool, which I find arcane). I know that the gettext stuff that ships with fetchmail's tarball matches what's needed and is fine, and that the configure.ac patches that require us to run autoreconf (actually, only autoconf, not even aclocal) will not require autopoint. Perhaps I should propose another change to the port to its maintainer (Corey Halpin) to reduce the ifs and buts to one unconditional "autoconf" run in pre-configure and move on, rather than trying to convince portmgr@ that the current state of affairs around autoreconf isn't complete, and to convince autoreconf that it can waive running autopoint... Introducing gettext dependencies, however, for a port that can well live without as long as the NLS option is disabled, is certainly not viable.
Sigh... So, you suggest running only autoconf, because you only modify configure.ac. Makes sense right? But it's wrong! And in the case of fetchmail autoconf itself warns about that because aclocal.m4 was generated for autoconf 2.68 while the ports tree runs 2.69. The fetchmail Makefile also lets aclocal.m4 depend on configure.ac, which means make will try to run aclocal during build, and fail since, because you only ran autoconf, it will look for aclocal-1.11 while the ports tree has 1.16. Then configure depends on aclocal.m4 so make will rerun autoconf. Furthermore, Makefile.in depends on configure.ac so it will run automake as well, and fail again because of a version mismatch. Makefile depends on config.status which depends on configure so make will rerun configure but without CONFIGURE_ENV and because configure got regenerated it will not have any of the modifications (current+future!) that the ports infrastructure applies to it. You could of course pile on more hacks to work around these things... I'm afraid you are only looking at this from the perspective of a single port. Portmgr has to check every change against 30000+ ports. For a single port hacks are maintainable. For 30000+ ports they are not. Hacks are inefficient at that scale. They break way too often. If adding a build dependency eliminates hacks and is more likely to keep build scripts in the work directory in a consistent state then we add the build dependency. If you look at how much easier post-USES=autoreconf autotools updates are compared to the USE_AUTOTOOLS days then this approach is clearly the right one. If you still insist on keeping hacks I reserve the right to mark the port broken if it ever fails to build in an exp-run. Please just add USES=gettext-tools and move on to something more important.
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.
and yes, just to make this explicit: I was implicitly proposing that gettext-tools be pulled in automatically by autoreconf, at least if AM.*GETTEXT is found in configure.{ac,in}.
(In reply to Matthias Andree from comment #5) > There are valid reasons to globally disable NLS through /etc/make.conf, for > instance, on embedded systems. But that is not a problem because gettext only gets there as a build dependency, and embedded systems will not build their own packages, a real computer will run poudriere for them.
(In reply to Mathieu Arnold from comment #12) This is again presumptuous and does not rectify the underlying issue... So, can I expect a decision towards the issues raised in comment #10 from portmgr@, or are we to shoot down any sane argument that might be representing user concerns, such as those offered in this thread while at the same time making it unnecessarily hard for less experienced porters to contribute? https://lists.freebsd.org/pipermail/freebsd-questions/2018-October/283052.html I understand scalability issues, but I do not accept diversions that have been proposed not only once...
A commit references this bug: Author: tijl Date: Mon Jan 14 17:01:23 UTC 2019 New revision: 490303 URL: https://svnweb.freebsd.org/changeset/ports/490303 Log: Improve autoreconf documentation. Clarify that autopoint and libtoolize are provided by devel/gettext-tools and devel/libtool respectively and that a build dependency on these ports is necessary if autoreconf wants to run them. PR: 234833 Changes: head/Mk/Uses/autoreconf.mk
So, what do you propose as our conclusion to this PR? It can't remain "New" forever.
(In reply to Matthias Andree from comment #15) I'm not sure what to do with this bug. It's too open-ended now. For the original problem I'd say Closed Works As Intended. If you want more documentation, I'm happy to review patches. If you want a tool that scans configure.ac and gives a list of dependencies that's not something I'm going to work on. I think autoreconf already fits that bill. It prints plenty of messages when it encounters problems. If some of these are difficult to understand then that's a documentation problem again.
(In reply to Tijl Coosemans from comment #16) I've also re-read things. Can we revisit comment #3? Have we solved the underlying scalability problem of "USES=autoreconf" being incompatible with NLS disabled? The thing is each and every port that USES=autoreconf would (back then) require workarounds for the NLS=off case or else fail to build. This doesn't scale well in my book. That's why I was proposing to fix the framework instead.
In make syntax it's not easy to scan configure.ac and then modify BUILD_DEPENDS, so I would say it's not feasible to fix the framework. In ports like fetchmail you really should just use: USES=autoreconf gettext-tools NLS_USES=gettext-runtime That's easier for you to maintain and easier for me as autotools maintainer. In a way, disabling the NLS option does not mean without gettext, it means without natural language support. It's perhaps unfortunate that it may still need gettext, but so be it. As a build dependency it's not a big deal imho. It would be different if it was a run dependency. Autoreconf doesn't just need autopoint by the way, it also needs gettext.m4 to get the definition of the AM_GNU_GETTEXT macro. Presumably, fetchmail has a bundled copy of gettext.m4, but that's not something the framework can rely on.
(In reply to Tijl Coosemans from comment #18) Moin moin Has everything been resolved? If not, please re-open the issue. mfg Tobias