Paul Eggert wrote:
> > it can define GNULIB_STRSTR itself:
> >
> > dnl Tell gnulib that the non-i18n implementation of strstr() is enough
> > dnl for our purposes.
> > AC_DEFINE([GNULIB_STRSTR], 1)
>
> This sounds a bit fragile. mountlist can use a non-i18n
> version of strstr but maybe some mountlist-using apps can't.
Yes, you're right. This looks like a dead end to me too.
> OK, but there are two categories of users here.
> First, maintainers want to detect portability problems.
> Second, installers don't want to be bothered about
> portability problems that do not apply to their platforms.
Yes, this an important observation. Maybe some -DGL_something flag
can distinguish the two cases (see below).
> The current approach caters to maintainers but will cause
> problems for installers. In the long run this means we'll
> have tarballs leading to installation failures in the field
> that are entirely avoidable.
That's not the case. In string_.h the
# define stpcpy stpcpy_is_unportable__...
is defined if and only if the module 'stpcpy' is not used in the scope
of the configure.ac. This is a platform independent condition (although
it's config.status which substitutes the @GNULIB_STPCPY@ variable).
Therefore all problems that installers would face from this technique
will be noticeable by the maintainer already.
> Also, to be honest it's getting a bit hard for me to
> follow/understand all this stuff. I'd like something
> simpler, or at least something more consistent. When
> maintaining this stuff I get lost about the distinction
> between GNULIB_STRSTR versus REPLACE_STRSTR versus
> HAVE_DECL_STRSTR versus DECL_STRSTR versus 'defined strstr".
> All these identifiers have their roles which make sense
> individually, but the combination is a bit much.
Indeed that deserves some documentation. Here is a beginning:
"
- 'defined strstr' tests whether the system has defined 'strstr'
as a macro.
- HAVE_STRSTR tests whether the system has defined 'strstr' as a function.
This is a C macro that is defined to 1 for true, and undefined or
defined to 0 for false. When used as an AC_SUBSTed variable, it always
has a value: 1 for true, 0 for false.
Some facilities can be defined either as macros or as functions; this is
why we use
#if !defined iswspace && !HAVE_ISWSPACE
/* Here define our own iswspace function. */
#endif
- REPLACE_STRSTR denotes the fact that gnulib provides a replacement
function for 'strstr'. Often the only portability problem that exists
is only that a function is missing; then REPLACE_STRSTR = ! HAVE_STRSTR.
The other case is when the function has bugs on some platforms, and
gnulib provides a substitute as a workaround against the bugs. In this
case REPLACE_STRSTR and HAVE_STRSTR may be true simultaneously.
- HAVE_DECL_STRSTR denotes the fact that the system provide a declaration
of 'strstr'. Sometimes system don't declare functions that they actually
have; in this case we use
#if !HAVE_DECL_STRSTR
/* Here declare the function strstr. */
#endif
to provide the missing declaration. Sometimes systems declare functions
that they don't have, but this is so rare that we normally can assume
that HAVE_DECL_STRSTR implies HAVE_STRSTR.
- GNULIB_STRSTR denotes the fact that the gnulib module 'strstr' is in use.
In this case the programmer can rely on strstr() to be available even
if ! HAVE_STRSTR - because gnulib provides a substitute if necessary.
"
> How about something along the following lines instead? It
> tries to be simpler, or at least more consistent. This
> would be put in string_.h, for each function that string_.h
> declares.
>
> #if @REPLACE_STRSTR@
> # undef strstr
> # define strstr @[EMAIL PROTECTED]
> #endif
> #if @REPLACE_STRSTR@ || ! @HAVE_DECL_STRSTR@
> extern char *strstr (char const *__haystack, char const *__needle);
> #endif
>
> @REPLACE_STRSTR@ is:
>
> 1 if configure determines that
> we need to replace the system strlen
>
> 0 if configure checked the system strlen and found
> it to be OK.
>
> _GL_CHECK_PORTABILITY otherwise.
Hmm, I would much prefer if we could keep the facility for replacement / fixup
of portability problems separate from the facility for detecting the portability
problems. Otherwise setting _GL_CHECK_PORTABILITY may hide portability
problsm - which would defeat its purpose.
> Maintainers can compile with -D_GL_CHECK_PORTABILITY to
> enable portability checking.
Yes, I'm thinking in the same direction.
> @RPL_@ is normally rpl_ but could be something else if we
> want to support multiple libraries.
You don't need this. You can use rpl_ always. The 20-line makefile command
that I use in gettext-tools/libgettextpo/Makefile.am solves the problem
of namespace cleanliness.
Bruno
