Hi Bruno, Bruno Haible wrote: > Hi Bruce, > >> gnulib-izing sharutils > > You are welcome to send a one-line patch to gnulib/users.txt!
Sure. Be happy to. First, though, I think I need to get sharutils working.... >>> Notice from module error: >>> If you are using GNU gettext version 0.16.1 or older, add the following >>> options >>> to XGETTEXT_OPTIONS in your po/Makevars: >>> --flag=error:3:c-format --flag=error_at_line:5:c-format > > It cannot be easily suppressed, because gnulib-tool is run before the > gettext macros are collected by 'aclocal'. > > Would it remove the confusion if I would add the following sentence to the > notice? > > "If you are using GNU gettext version 0.17 or newer, you can ignore this > notice." I did figure that much out. At issue is whether this is strictly relevant for the tool manufacturer (e.g. "me" for sharutils), or the builder (the aforementioned "hapless builder of sharutils"). I also thought that gtver=$(gettext --version|head -1|sed 's/.*) *//') would readily answer the question. At least for the tool manufacturer. :) > The order should be > > AC_PROG_CC > gl_EARLY > gl_INIT > > The doc > <http://www.gnu.org/software/gnulib/manual/html_node/Initial-import.html> > suggests > "invoke gl_EARLY in ./configure.ac, right after AC_PROG_CC," > and > "... the macro gl_INIT. Place it further down in the file, typically where > you normally check for header files or functions." OK. I'm convinced. The gnulib (and autoconf!!) need a manual section that categorizes the various macros and specifies the proper ordering of the categories. That tidbit was 3/4 the way down a long web page among plenty of other web pages one has to read and understand. Maybe I'm dumb and lazy, but I do find it difficult to juggle it all..... > But there is a known problem with AC_USE_SYSTEM_EXTENSIONS in autoconf <= > 2.63. > I'd suggest to use autoconf 2.64 and then remove all invocations of > AC_GNU_SOURCE. Since I don't have any at all, that should be fairly simple. However: > $ autoconf --version > autoconf (GNU Autoconf) 2.64 and I still see the warning: configure.ac:22: warning: The macro `AC_GNU_SOURCE' is obsolete. (and, no, line 22 does not say AC_GNU_SOURCE on it.) >> * I get a whole mess of messages like this. Since none of this appears in >> either >> configure.ac nor m4/sharutils.m4, I'm guessing some macro some where pulls >> it in. >> It is hard to trace though: >>> $ ls ../../../lib/autoconf >>> ls: cannot access ../../../lib/autoconf: No such file or directory >> So, to the messages: >> >> configure.ac:21: warning: The macro `AC_TRY_RUN' is obsolete. > > You can ignore these warnings. AC_TRY_RUN and AC_TRY_LINK cannot go away > because hundreds of autoconf macros use them. Then the warnings should go away: >> configure.ac:21: note: The macro `AC_TRY_RUN' is an obsolescent macro. \ >> please avoid using it. Such a message would be much less disconcerting. :) The whole thing ends with this: > configure: creating ./config.status > config.status: creating src/remsync > config.status: creating src/compress-dummy > config.status: creating contrib/Makefile > config.status: creating doc/Makefile > config.status: creating intl/Makefile > config.status: creating lib/Makefile > config.status: creating po/Makefile.in > config.status: creating src/Makefile > config.status: creating src/mail-files > config.status: creating src/mailshar > config.status: creating tests/Makefile > config.status: error: cannot find input file: `Makefile.in > $ ls -l Make* > -rw-r--r-- 2 bkorb dev 1049 Aug 30 11:18 Makefile.am > $ sed -n '/^AC_CONFIG_FILES(/,/AC_OUTPUT/p' configure.ac > AC_CONFIG_FILES([ > contrib/Makefile > doc/Makefile > intl/Makefile > lib/Makefile > po/Makefile.in > src/Makefile > src/mail-files > src/mailshar > tests/Makefile > Makefile > ]) > AC_OUTPUT Would you like the entire configure run output? Would that give some more clues? Thank you, Bruno, for your help!! Regards, Bruce
