Re: planning for beta-testing gnulib-tool.py

[Simon Josefsson]

Bruno Haible <bruno@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