Dima Psechnik wrote: > We are in fact having a fight now over whether to check in the > iconv pieces produced by gnulib-tool into the source tree, or call > gnulib-tool at bootstrap. > https://trac.sagemath.org/ticket/34152
OK, now let's talk about the actual problem at hand. I won't jump into the discussion there, because - it's already a very long thread, - I don't know what an "SPKG" is, - I don't know about the preferred habits in the sagemath dev community. But there I read: > $ du -sh config/config.rpath m4/lib-*.m4 m4/iconv.m4 m4/host-cpu-c-abi.m4 > 20K config/config.rpath > 8.0K m4/lib-ld.m4 > 36K m4/lib-link.m4 > 12K m4/lib-prefix.m4 > 12K m4/iconv.m4 > 24K m4/host-cpu-c-abi.m4 Yes, these is currently the list of files needed for AM_ICONV. > It's some kind of a weird tradition of jumping through hoops to get > config.rpath If you need only a few files from Gnulib, the common approach is to invoke either gnulib-tool (if present, indicated through an environment variable GNULIB_SRCDIR that the user can set) or fetch the files from the git repository one by one. To fetch only config.rpath: GNULIB_REPO_URL="https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;hb=HEAD;f=" for file in build-aux/config.rpath; do if test -n "$GNULIB_SRCDIR" && test -d "$GNULIB_SRCDIR"; then "GNULIB_SRCDIR/gnulib-tool" --copy-file $file $file else wget -q --timeout=5 -O $file.tmp "${GNULIB_REPO_URL}$file" \ && mv $file.tmp $file fi done To fetch all 6 files: GNULIB_REPO_URL="https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;hb=HEAD;f=" for file in build-aux/config.rpath m4/lib-ld.m4 m4/lib-link.m4 m4/lib-prefix.m4 m4/iconv.m4 m4/host-cpu-c-abi.m4; do if test -n "$GNULIB_SRCDIR" && test -d "$GNULIB_SRCDIR"; then "GNULIB_SRCDIR/gnulib-tool" --copy-file $file $file else wget -q --timeout=5 -O $file.tmp "${GNULIB_REPO_URL}$file" \ && mv $file.tmp $file fi done This is the quick solution, which minimizes network traffic. But it is not future-proof: At any moment, some more files may become needed, due to changes in the *.m4 files. The future-proof solution is to download the gnulib git repository (shallow, if you want) and run $GNULIB_SRCDIR/gnulib-tool [OPTIONS] --import iconv > I don't quite understand the relationship between automake, gettext, and > gnutools here. Is AM_ICONV even meant to work without gnulib? > Or is it a libtool bug? AM_ICONV is documented in two places: - https://www.gnu.org/software/gettext/manual/html_node/AM_005fICONV.html - https://www.gnu.org/software/gnulib/MODULES.html#module=iconv The consumption as a gnulib module is meant to be easier than through gettext. A lot of work has been put into gnulib to make such a consumption easy; gettext (autopoint) lags behind in this aspect. > https://lists.gnu.org/archive/html/bug-gettext/2011-10/msg00012.html Already in 2011, if you need only AM_ICONV, the gnulib module 'iconv' was the better choice. > config.rpath (in gnulib) appears to be an orphan. No. It is maintained in gnulib, as you can see from the commit history. > (Does gettext misappropriate prefixes AM_ and > AC_ for its macros, making an impression that they are from autotools?) Yes, the prefix AM_ here is a mistake. It should better be gl_. But changing it now would cause more annoyance than benefit. Bruno