Follow-up Comment #5, sr #111238 (group autoconf): Zack:
> the intended purpose of autoreconf is to be a complete substitute for > project-specific autogen.sh scripts. The documentation https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/html_node/autoreconf-Invocation.html disagrees: It implies that autoreconf is a complete substitute for a project-specific autogen.sh *only* if that autogen.sh script makes use only of autoconf, autoheader, aclocal, automake, libtoolize, intltoolize, gtkdocize, autopoint and nothing else. Nothing else: No gnulib-tool, no libtool.m4 patches, no 'git clone' of other repositories, no 'git submodule init'. (I'm not arguing for 'autoreconf' to do 'git clone' or 'git submodule init': It has become clear that fetching sources through the network and generating files are two tasks that are best kept separate; this is where the distinction between 'autopull.sh' and 'autogen.sh' comes from.) > If I understand the discussion at https://savannah.gnu.org/bugs/?67090 and > https://savannah.gnu.org/bugs/index.php?66968 correctly, a change in gettext > broke building certain older packages from source. To keep a long story short, I'll focus on two points: 1) In the beginning (before 2002), there was only one tool for adding gettext's build infrastructure to a package: gettextize. Then it became clear that the manual invocation (wizard-like tool) and the automated invocation (part of what autogen.sh does) are two different situations, and 'autopoint' was created for the latter. One of the main differences is that 'gettextize' installs the infrastructure for the *current* gettext version, whereas 'autopoint' installs the infrastructure for the gettext version that has been agreed upon among the package developer team. Both 'gettextize' and 'autopoint' make sure that what they install is consistent, that is, that po.m4 and po/Makefile.in.in come from matching versions. This constraint is important, because without it, po.m4 could not evolve and po/Makefile.in.in could not evolve either. 2) The gettext .m4 files were installed into $prefix/share/aclocal/ without the intention to make them available for 'aclocal' or 'autoreconf'. It was simply because other packages install their .m4 files there as well. When a user has two different ways to do the same thing, it is tedious to keep the two ways in sync, that is, do the equivalent things. And this is what happened: For some packages, 'autoreconf --install' invoked just aclocal, not autopoint. For many years, this behavioural difference 'autoreconf --install' vs. 'autopoint' hardly mattered, because po.m4 hardly changed. But with gettext 0.24, there were significant changes in po.m4 and po/Makefile.in.in, and while 'autopoint' handled the situation well, 'autoreconf --install' did not. Therefore the fix that I did in 0.24.1 was to make it impossible for 'autoreconf --install' to produce the broken situations that were reported (in https://savannah.gnu.org/bugs/?66968 , https://savannah.gnu.org/bugs/?67090 , https://lists.gnu.org/archive/html/bug-gettext/2025-03/msg00040.html ). This change should have been done at the moment 'autopoint' was invented, but I did not realize it at that time (in 2002). > I'd appreciate it if you could suggest any approach to threading a path > through all these semi-contradictory requirements. Here are some thoughts about it. 1) The GNU Build System should be more consequent in offering to the user one and only one way to do a specific thing. I discussed 'autopoint' above. The same problem exists for 'libtoolize': It has its .m4 macros stored in $prefix/share/aclocal/ as well (see https://packages.debian.org/bookworm/all/libtool/filelist ). If someone runs 'autoreconf --install' and autoreconf guesses wrong about the need to invoke libtoolize, the user will get a libtool.m4 file that does not match the version of their ltmain.sh. Another example (unfortunately) is that the gettext manual documents the AM_ICONV macro. This should be in Gnulib only, but some old packages use 'autopoint' to get AM_ICONV. 2) autoreconf should have a more solid recognition which tools it should invoke. There is the case of packages with AM_GNU_GETTEXT invocations without AM_GNU_GETTEXT_VERSION. There is also the case when no .m4 files are present in the package, and the package invokes some PKG_CHECK_MODULES macro. I've seen autoreconf fail in such a situation, IIRC, because autoreconf runs autom4te and autom4te fails. 3) autopoint should handle all cases. Currently in the case of packages with AM_GNU_GETTEXT invocations without AM_GNU_GETTEXT_VERSION, it bails out. 4) autoreconf should invoke autopoint in such cases as well. > perhaps it is not doing it correctly. What it currently does is grep > configure.ac for occurrences of AM_GNU_GETTEXT_(REQUIRE_)?VERSION. There is room for improvement, indeed: https://savannah.gnu.org/bugs/?52424 > there exist projects that "intentionally don't call > AM_GNU_GETTEXT_(REQUIRE_)VERSION because they have all of the gettext > infrastructure checked into version control and they want [autoreconf] to not > run autopoint"; any change will need to not break such projects. This is a symptom of the tension between package maintainers and distros: 1) When package maintainers do a release, they test a specific tarball, with generated files from a specific autoconf version, a specific automake version, a specific GNU bison version, a specific GNU gperf version, a specific makeinfo version, a specific groff version, and so on. But then the distros say "we don't trust upstream tarballs any more, because of the xz backdoor drama", and regenerate everything with their own versions of autoconf, automake, bison, gperf, makeinfo, groff, etc. 2) Distros typically ignore it when the upstream maintainer says "my package does not support autoreconf". They run autoreconf anyway. You (or we, in the GNU Build System) cannot solve this tension between package maintainers and distros. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/support/?111238> _______________________________________________ Nachricht gesendet über Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
