Re: config.rpath conflict

[Bruno Haible]

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