Bruno Haible <br...@clisp.org> writes:
> I guess we are thinking about slightly different things:
>
> * (A) I am thinking about
> - for P in { coreutils, gettext, ... }, taking a frozen(!) checkout of P,
> removing irrelevant source files (esp. all *.h, *.c, documentation,
> etc.),
> - and a frozen(!) set of gnulib modules at a specific time point,
> - and merely invoke gnulib-tool and compare the generated files and
> stdout.
>
> * (B) You seem to be thinking about
> - for P in { coreutils, gettext, ... }, taking the current git of P
> (or latest release of P),
> - taking the current set of gnulib modules,
> - and invoke not only gnulib-tool, but also './configure' and make.
>
> I think that
> - With either approach, the confidence to any change in gnulib-tool will be
> the same.
> - With approach (A), when we make a change to gnulib-tool, we need to commit
> new expected test results, which is quite easy. No effort otherwise.
> - With approach (B), we will get failures for other reasons as well: when
> a gnulib module has changed in an incompatible way; when the git
> repository
> of P has moved; when package P itself is broken. Sounds like a continuous
> effort to hunt down (mostly) false positives.Right, I agree! I wonder when/if we could get rid of gnulib-tool.sh? Maintaining both would be time-consuming. Maybe we have to declare some features no longer supported if they cannot be implemented easily in gnulib-tool.py... /Simon
signature.asc
Description: PGP signature
