Bruno Haible <[email protected]> writes:
>> So I think it is worth mentioning
>> that projects like sed will need to use the --tests-base option.
>
> No, that would add constraints between things that better stay
> independent:
> - the import of Gnulib tests into the package (if desired),
> - the use of init.sh for the package's own tests.
I think my short explanation may have caused a misunderstanding. I was
trying to point out that 'gnulib-tool --copy-file tests/init.sh' relies
on a project using the 'tests' subdirectory for their own test suite.
This is not the case for GNU sed. Here is my clean checkout:
$ find . -name 'init.sh'
./testsuite/init.sh
Then after running ./bootstrap to import Gnulib:
$ find . -name 'init.sh'
./gnulib-tests/init.sh
./testsuite/init.sh
Here is why 'gnulib-tool --copy-file tests/init.sh' is not correct:
$ stat tests
stat: cannot statx 'tests': No such file or directory
$ gnulib-tool --copy-file tests/init.sh
Copying file tests/init.sh
$ ls tests
init.sh
So the file is placed in the wrong directory. The 'tests' sudirectory is
created silently. My solution was to use --tests-base to adjust the
location of the file. In a clean checkout:
$ gnulib-tool --tests-base testsuite --copy-file tests/init.sh
$ git status --short
M testsuite/init.sh
Though this would work too and is probably more clear:
$ gnulib-tool --copy-file tests/init.sh testsuite/init.sh
I assume the use of --tests-base caused some confusion here since that
is used for importing the Gnulib test suite. It felt a bit strange to me
atleast, but it worked.
Collin
