Simon Josefsson wrote: > 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?
Should "gnulib-tool --update" copy some specific older version of gnulib into the package's sources, identified by a commit identifier? Or should simply autopoint refrain from overwriting gnulib-imported files (will be in gettext 0.18)? > 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. Would it help to have an option for gnulib-tool that avoids running configure, knowing that it will be run afterwards anyway? Currently gnulib-tool invokes configure and make for generating distributed built files (i.e. running bison, gperf, or similar unusual tools). Bruno
