Bruno Haible <br...@clisp.org> writes: > Simon Josefsson wrote on 2009-08-31: >> > Until then, you have to overwrite autopoint'ed files with copies brought in >> > by gnulib-tool. >> >> Is this still the recommended practice for using autopoint and >> gnulib-tool together? >> >> I ran into an issue where size_max.m4 imported by autopoint was older >> than the copy provided by gnulib. > > Yes, exactly this can happen. Documented in > > <http://www.gnu.org/software/gnulib/manual/html_node/gettextize-and-autopoint.html>
Right, but the solution assumes that people building my software from version controlled sources has installed the same version of gnulib that was used when my software was committed to the repository. I don't think that is reliable in the long run, or rather, it is clearly non-reliable even today since the gnulib APIs has changed. Isn't there any other solution? >> Overwriting the m4 files created by >> autopoint with gnulib-tool causes autoconf, automake, ./configure etc to >> be re-run before 'make' works, which significantly slows down building >> my projects, so I'd like to find some other solution. > > autopoint and gnulib-tool are both in the same category of tools: They > fetch missing files from elsewhere. autoconf, automake come later: They > generate files from given files. configure and make come afterwards. > > In regular development, I would expect that you regularly modify some > configure.ac or Makefile.am, which don't require autopoint or gnulib-tool > to be run. Only seldom you decide to require more gnulib modules. No? Right, but I don't see how to turn that information into a solution to my problem. As an example, my daily auto-builder checks out the sources, run autoreconf and then overwrites the m4 files created by autopoint with the gnulib-tool copies. This causes ./configure etc to be re-run twice every time it is built. This is sub-optimal and the only cause are the autopoint m4 files. /Simon
