RE: Tests that fail due to iconv()

[Avis, Ed]

Bruno Haible <address@hidden> wrote:

>>Surely if a particular iconv() feature needed, the configure 
>>script should check for this?
>
>GNU gettext optimally works with a reliable and IANA standards 
>compliant iconv(). Whether GNU gettext is still usable without it, 
>depends on your intended use of the gettext programs.
>
>>Then either the user can be prompted to install GNU libiconv
>
>Configure scripts should be non-interactive and not "prompt the user".

I meant the configure script can print a message 'your iconv library
is broken, please install GNU libiconv' and then exit.  Or there could 
be an --allow-broken-iconv configure option, for users who are sure
that their use of gettext won't be affected by their local iconv().

>>or at least certain tests can be 'skipped on this platform'
>>rather than failed.
>
>If I did this, you would get the wrong impression that the gettext
>binaries without a good iconv() are well usable, which is not
>necessarily the case.

OK.

But surely, if gettext is not usable without a good iconv(), then
configure should check for common broken implementations, or do some
basic sanity checking that important features are supported.

If you give the user the option to proceed anyway, then tests which
rely on the missing iconv() features should be skipped.

What's bad is if the configure test (which is supposed to detect
missing features on your platform) seems to work without giving any
warnings, and then the test suite fails.  Although the early test
suite failure messages (if not all of them) did give a clear
explanation of what was wrong, so perhaps this is okay.

-- 
Ed Avis <address@hidden>